Initial Enrolment Project Feasibility Draft Report Consultation Document

Transcription

1 Initial Enrolment Project Feasibility Draft Report Consultation Document Date issued: 11/11/2016 Consultation closes: 20/01//2017 Classification: DCC Public

2 Contents 1 Executive Summary Introduction Technical Options Introduction Integration Path Options SMETS1 DCC User Interface Options Service Request Functionality: Communication Services Options Prepayment Options Security 4.1 Introduction Analysis of Security Aspects of Technical Options Analysis of Security Options Security Conclusions Consultation Questions Service Delivery Service Management and Service Desk Evaluation against Criteria Business Continuity Consultation Questions Commercial Approach Context and Structure of this Section Summary of Procurement Requirements Procurement Options Procurement Strategy and Approach Commercial Considerations for Design Procurement Timescales Commercial Delivery Confidence Consultation Questions Implementation Introduction Components of the Infrastructure Enabling consistent assessment of timescales Implementation Option Implementation Option IEPFR Consultation DCC Public Page 2 of 144

3 7.6 Implementation Option Comparison of Options End State Vision Conclusions Consultation Questions Costs and Charges Background Core cost elements Model Implementation Key Assumptions Indexation and Discounting Outputs for the IEPFR Sensitivities Charging Premium Summary Consultation Questions SMETS1 Services under the SEC Enrolment process Communication Services Process for enrolling SMETS1 Meters Becoming an eligible user for SMETS1 enrolment and communication services Security Communications Hub Services Other Enabling Services Data Privacy Charging for SMETS1 Services Material changes to Section M of the SEC Appendix A Definitions & Acronyms Appendix B Consultation Questions Appendix C Assessment Criteria Appendix D Analysis of Communication Services Appendix E Current SMETS1 vs. SMETS2 model for Prepayment Appendix F Adoption of Communications and/or Novation of SMSO contracts: Approach and Due Diligence Process Appendix G Enrolment Options Testing: Summary Appendix H Summary of Technical Options IEPFR Consultation DCC Public Page 3 of 144

4 1 Executive Summary 1.1 Introduction The infrastructure for existing SMETS1 meters has developed organically without a unified communications standard and often independently, to meet energy suppliers own requirements, according to their own business needs. As such, meters installed by one supplier are not always compatible with another suppliers system and could lose functionality or require replacement when consumers switch supplier. The Government believes that there are important shared benefits for industry and consumers from the enrolment of SMETS1 meters into the Data Communications Company (DCC). In particular, the enablement of more efficient and effective switching for customers, as a gaining supplier will be able to access the smart meter functionality should a consumer switch suppliers. Consequently this should reduce the risk of SMETS1 meters being replaced before the end of their operating lives. In order to achieve the objective of maximising the benefits of smart metering, the Government has requested DCC to carry out a study of feasible options for the enrolment of SMETS1 meters. Section N of the Smart Energy Code (SEC) requires DCC to produce an Initial Enrolment Project Feasibility Report (IEPFR) relating to the enrolment of SMETS1 meters and to consult parties on the content of the draft report. In identifying feasible options for the provision by DCC of a SMETS1 Service, DCC needs to take as its starting point the existing multiple technical solutions and systems that have developed to support SMETS1 meters, and consider how technical and commercial arrangements can be structured to enable the provision of a DCC SMETS1 Service. DCC s objective has been to identify feasible options that whilst technically effective, commercially efficient and secure, are delivered for a reasonable cost and within reasonable timeframes. The IEPFR has been developed by DCC and represents the key findings of this feasibility stage assessment including analysis supporting a range of technically and commercially feasible options, and other relevant factors, for achieving the provision of a SMETS1 enrolment capability by DCC. Stakeholders are invited to respond to the content set out in this draft report. 1.2 Approach to Analysis DCC has considered a number of ways to provide a SMETS1 service and in doing so has excluded those that it considers to be infeasible or undeliverable. The options that remain have been evaluated in this draft report. Essentially, optionality exists in the integration path, SMETS1 DCC user interface, Communication Services, Prepayment, Security, and Service Delivery, with choices also in the commercial approach and the implementation strategy. This draft report evaluates these areas of optionality and, through this analysis, identifies a range of possible implementation approaches, each of which has different advantages with respect to time, cost and deliverability. In preparing the IEFPR, DCC is not required to conclude on a preferred implementation approach, rather to set out the feasibility of various approaches. However, the relative merits of each area of optionality should be IEPFR Consultation DCC Public Page 4 of 144

5 clear to the reader and this should allow parties to constructively respond to this consultation. 1.3 Summary of Analysis of Technical Options This report assesses the technically feasible options for four elements that, together, describe key features of the technical solution required to deliver a SMETS1 enrolment capability with DCC. These technical elements, along with feasible options for each, are: Integration path Integration path covers the means by which DCC can communicate with SMETS1 meters to enable it to first enrol the meters and then send commands to and receive messages from enrolled SMETS1 meters. A range of potential integration path options were considered (as set out in section 3.2.3). Upon analysis, DCC considered that certain integration path options were not appropriate to be considered in more detail. As a result, the analysis concludes that there are two technically feasible integration path options, as follows: establish communications between a new SMETS1 data service (procured by DCC) which integrates via existing SMETS1 communications service providers (CSPs) to the meter (i.e. integrate to meter ); and establish communications with the existing SMETS1 data services capability (known as the Smart Meter Systems Operator (SMSO)), which integrates, via existing SMETS1 CSPs, with the meter (i.e. integrate to SMSO ). Both of these options are technically feasible and deliverable within time/cost parameters and as part of this consultation, DCC is inviting views on each of them. SMETS1 DCC user interface SMETS1 DCC user interface covers the means by which users can communicate with DCC to enable suppliers to enrol SMETS1 meters with DCC and to enable all eligible users to send messages to and receive messages from enrolled SMETS1 meters. When considering SMETS1 DCC user interface options DCC has considered both the format in which messages are sent to DCC by users and the provision of the interface for sending SMETS1 service requests and receiving responses. As a result, DCC s analysis concludes that there are three technically feasible SMETS1 DCC user interface options, as follows: the creation of a SMETS1 DCC user interface with message formats based on the SMETS2 DUIS and the interface provided by the SMETS2 Data Service Provider (DSP); the creation of a SMETS1 DCC user interface with message formats based on the SMETS2 DUIS but with the provision of the interface competitively procured, and the creation of a new SMETS1 message format with the provision of the interface competitively procured. All three options are technically feasible and deliverable within time/cost parameters and as part of this consultation, DCC is inviting views on each of them. IEPFR Consultation DCC Public Page 5 of 144

6 Service Request Functionality In designing a DCC SMETS1 service, the functionality that DCC will provide to users in accessing enrolled SMETS1 meters needs to be defined. This is done by specifying a set of service requests, being the core communication services that are available for all enrolled SMETS1 meters. A range of potential options were considered (as set out in section 3.4.2). Upon analysis, DCC considered that certain options were not appropriate to be considered in more detail. As a result, DCC s analysis concludes that there are three technically feasible options for the list of core communications services that are offered, as follows: DCC provides the required minimum SMETS1 Services (37 Services) for all DCC enrolled SMETS1 meters, as defined in the SEC. DCC provides the services currently supported by each of the SMETS1 SMSOs which, in the case of some meter cohorts, would result in the provision of less than the minimum 37 service requests (in this context a cohort is a unique combination of supplier, SMSO and CSP). DCC provides the services currently supported by each of the SMETS1 SMSOs, as per the second option, but with a phased introduction to reach the minimum 37 SMETS1 Services. All three options are feasible, but one option would require enhancements to SMSO services if the integrate to SMSO integration path is chosen, and another becomes invalid if the Integrate to meter integration path is selected. DCC also notes that, to the extent that there are other communication services that a supplier has available to it but that are not provided as part of the core DCC offering, that, as with SMETS2 service provision, these could be provided as elective communication services. Prepayment Prepayment options relate to how to support the functioning of DCC enrolled SMETS1 meters operating in prepayment mode. The feasibility options analysis for meters operating in prepayment mode focuses on the generation of a Unique Transaction Reference Number (UTRN) which is required for the topping up of a SMETS1 meter operating in prepayment mode. Based on the analysis performed to date, there are three feasible UTRN generation options, as follows: DCC provides a centralised managed service which generates UTRNs on request of either a payment service provider or an energy supplier, where either the payment service provider or the energy supplier can request the UTRN (which is then passed back to the requestor); and DCC provides a centralised managed service which generates UTRNs on request of the energy supplier only (which is returned to the energy supplier only). The energy supplier would then pass the UTRN to the payment service provider (if requested), as per the anticipated operating model for SMETS2 meters. DCC providing a standardised UTRN generation function for energy suppliers to integrate into their systems. For this option, DCC would produce UTRN generation software that suppliers integrate into their systems. IEPFR Consultation DCC Public Page 6 of 144

7 Other aspects of DCC SMETS1 Services to support prepayment are also considered. First, the process for submitting over the air top up requests is explored, specifically whether the process should be a one step process which is triggered when the UTRN is requested, or a two-step process with separate requests for UTRN generation and the sending of the over the air top up request. Second, the provision of the interface for requesting UTRNs (a feature of options one and two) is explored considering the advantages and disadvantages of this being separate from the SMETS1 DCC user interface. All three options are feasible and have little impact on the whole life cost of the SMETS 1 solution. 1.4 Security The SEC requires DCC to detail security measures (including systems) that would be required to ensure that there is no material increase to the security risk of the whole smart metering system as a consequence of DCC providing SMETS1 Services. As such, this element of the draft report sets out a range of options to achieve this objective. Should a path of integrate to SMSO be chosen, the degree to which these measures would need to be applied is, in part, a function of what security controls currently exist in SMSO systems. This draft report is supplemented by a security appendix which has been redacted for security reasons. The SEC Panel has directed these redactions, as required by the SEC. The security controls considered include: Public Key Infrastructure (PKI) authentication; system hardening; islanding; enhanced key management; CSP limitations and assurance of SMETS1 meters. 1.5 Service Management This section of the report sets out options for the provision of support and service management for SMETS1 meters enrolled into DCC. The draft report examines both the user facing aspects of service management and the internal systems and processes that the DCC uses to interface with service providers. This section recommends: the alignment of service management standards for SMETS1 with those established for SMETS2; the use of the SMETS 2 Self Service Interface (SSI) and Service Desk; and the use of SMETS2 Incident Management and Error Handling procedures. This section also sets out two options for service delivery integration with existing SMETS1 service providers where the integrate to SMSO integration path is chosen; either integration with SMSO service management systems, or the provision of a DCC service management system. Finally this section recommends that further work is undertaken to consider the optimal business continuity arrangements where integrate to SMSO is chosen given that, presently, these are unique to each SMSO. 1.6 Commercial Approach This section of the report considers the commercial arrangements that DCC will need to put in place to support the delivery of the technical and security options outlined previously and possible procurement timescales. It explains that in some cases capabilities will need to be competitively procured (where no existing service provision exists). In other cases where options involve the utilisation of existing SMETS1 capabilities (for example, where DCC integrates to SMSO or when using existing communications networks), choices exist as to whether existing contractual arrangements are novated to DCC or whether DCC enters into new contracts. In other cases again, IEPFR Consultation DCC Public Page 7 of 144

8 DCC may need to amend the contracts of its existing SMETS2 services providers to deliver aspects of the functionality required under a particular option. As required by Section N of the SEC, DCC also sets out in this section its current view on the feasibility of adopting the existing arrangements for SMETS1 communication services. In this section, DCC sets out its view that overall commercial delivery confidence is high, but noting that flexibility is required in relation to the choice of integration path options, due to the commercial viability of different integration path routes potentially varying between meter cohorts. 1.7 Implementation This section of the report assesses the range of options to implement the overall SMETS1 enrolment solution. Implementation options centre on the technical integration paths analysed in the technical section of this draft report, but also take into account other areas of optionality and choice covered in other sections of this draft report, including commercial considerations and cost. As such, they provide a rounded assessment of the likely implementation options. In analysing delivery timescales, the core delivery phases required to deliver a SMETS1 enrolment solution, namely high-level design, procurement and design/build/test, are assessed for each option. This section also provides a comparative assessment of the implementation options on the basis of time, cost, risk and scope of service provision. The analysis concludes that there are principally three implementation options; the first option is based on the application of integrate to SMSO for all cohorts, whilst the second is based on the application of integrate to meter for all cohorts. Whilst both of these two options have advantages and disadvantages, DCC envisages that it may eventually interface directly with SMETS1 meters in the same ways as DCC communicates to SMETS2 meters today (i.e. integrate to meter). This is DCC s end-state vision whilst acknowledging potential constraints to achieving this. The third option is a hybrid, allowing choice of integration path dependent primarily on the rate at which DCC is able to achieve the end-state vision. This hybrid option enables the rapid enrolment of a high volume of SMETS1 meters, de-risks the development of the new DCC SMETS1 Service, and is sufficiently flexible to accommodate market developments aimed at achieving some level of interoperability ahead of enrolment into DCC. DCC is aware that SMETS1 market participants are considering ways to effect at least partial interoperability for certain cohorts of meters. DCC will consider, in the next phase of analysis, whether the hybrid approach mentioned above can be accelerated by integrating to this market led solution, and what the impacts of doing so would be from a commercial and technical perspective. 1.8 Costs & Charges DCC has developed a flexible and integrated cost model to underpin the cost analysis aspect of this project. Given the sensitivity of cost information, the cost model is not provided with this draft report, but has been separately shared with the Department for Business, Energy and Industrial Strategy (BEIS). Instead, this section provides a summary of the core cost elements, including their relative impact on the whole life costs of the three Implementation Options, and details the assumptions that underpin the costs in the model. It also covers the use of optimism bias and sensitivity analysis, and provides an assessment of the proposed approach to the recovery of costs of a SMETS1 IEPFR Consultation DCC Public Page 8 of 144

9 Service, including consideration of whether a premium charge would be payable in respect of adopted communications arrangements. It is important to recognise that this assessment does not take into account the potential benefits from greater interoperability of SMETS1 meters that enrolment with the DCC provides. These benefits include the maintenance of smart functionality on churn, reducing the risk a gaining supplier would need to replace the meter with another smart meter or temporarily run the meter in dumb mode. Enrolment with the DCC would also mean that DCC users such as Network Operators and Other users can make use of the functionality of SMETS 1 meters. 1.9 SMETS1 Services under the SEC The final section of the report considers the impact of the provision of a DCC SMETS1 Service on the SEC. It identifies some of the areas where the SEC may need to be updated to reflect the overall approach to enrolment Next Steps Following the receipt of responses to this consultation, DCC will update the report and submit the final IEPFR to the Secretary of State. The IEPFR presents a feasibility stage assessment of the technical, commercial and other relevant options for enrolment of SMETS1 meters into DCC. Consequently, the analysis provided is intended to reflect this phase of the overall initial enrolment project within DCC. The next phase of the project will include: the development of a detailed implementation strategy and approach based on the preferred options; continued commercial engagement to refine the commercial strategy; a second phase of Enrolment Options Testing (EOT) to shape the technical and commercial approach to development of the new SMETS1 data services provider, and other supporting work. The first phase of EOT comprised a technical research project investigating the integration of SMETS1 meters with the DCC. The second phase of EOT will comprise a technical research project investigating further the technical and security options for a DCC SMETS1 Service that are set out in this report; an assessment of the potential impact of a DCC SMETS1 Service on DCC existing operations (operationally and with respect to DCC s change capacity) and the formulation of any necessary measures to mitigate the impact; and analysis and planning for the enrolment of meters by multiple DCC users. This planning will include provisions to manage big bang risks for all parties. DCC will seek input from BEIS on which options should be selected for the purposes of progressing this next phase of work. DCC will continue to engage with industry in delivering this next phase of work. Additionally, if directed by the Secretary of State, DCC will develop the SEC amendments necessary to establish the regulatory framework for the provision of SMETS1 Services. IEPFR Consultation DCC Public Page 9 of 144

10 1.11 Consultation Each section of this report contains consultation questions and views on each of these questions are sought from stakeholders. Please provide responses by 20 January 2017 to DCC at If you have any questions regarding the content of this consultation, or our approach to consultations in general, please contact Tom Rothery at Consultation responses may be published on DCC s website. Further, DCC may refer to responses in its consultation conclusions, which will appear on DCC s website. Please state whether all, or any part, of your consultation response is confidential. Please note that responses may also be made available to the Gas and Electricity Markets Authority (GEMA) and the Department of Business, Energy and Industrial Strategy (BEIS). DCC shall analyse responses to the consultation and respond appropriately. A conclusion document will be published laying out DCCs responses to points raised in the consultation. DCC will then submit the IEPFR, including any updates as a result of the consultation, along with a report detailing consultation responses, to the Secretary of State. IEPFR Consultation DCC Public Page 10 of 144

11 2 Introduction 2.1 Background The Government's vision is for every home in Great Britain to have smart energy meters and for smaller businesses and public sector premises to have smart or advance metering by Smart meters are the next generation of gas and electricity meters. They will offer a range of intelligent functions and provide consumers with more accurate information, bringing an end to the need for estimated billing. Consumers will have near real-time information on their energy consumption to help them control and manage their energy use, save money and reduce emissions. Since 2009, Government has been engaged with the energy industry, consumer groups and other interested parties to explore the benefits of developing and then deploying Smart Meters throughout Great Britain. This engagement culminated in a deployment programme for smart meters split into two stages, Foundation (SMETS1 the focus of this consultation) and Enduring (SMETS2). 2.2 SMETS2 meters and DCC The chosen approach for delivery of smart meters required the development of a common set of standards for smart meters (SMETS2) and a single secure data and communications infrastructure that energy suppliers can connect compliant meters to (provided by DCC). On 23 September 2013, a new licensed entity, DCC, was established. Together with its service providers, the SMETS2 DSP and CSPs, DCC will provide the SMETS2 smart meter data and communications service. DCC will offer a means by which suppliers, network parties and others can communicate remotely with SMETS2 meters in Great Britain. A significant majority of the benefits of smart metering are expected to be delivered through the installation, enrolment and operation of SMETS2 meters through DCC. 2.3 SMETS1 meters A number of suppliers are already installing smart meters which are, or will be, compliant with the first iteration of the smart meter technical specification (SMETS1). SMETS1 was implemented in 2011 and set out a specification for a new breed of smart meters that could provide a core set of functions. Installation of SMETS1 meters has allowed for early benefits to be realised and also provide early learning for industry. These early SMETS1 meters are operating outside of DCC. Unlike the new infrastructure for SMETS2 Meters, the infrastructure for existing SMETS1 meters has developed organically without a unified communications standard and often independently, to meet suppliers own requirements, according to their own business needs. As such, meters installed by one supplier are not always compatible with another suppliers system and could lose functionality or require replacement when consumers switch supplier. Suppliers have advised DCC that, by the end of 2016, there will be an estimated two million smart meters installed that are SMETS1 compliant. They have further advised DCC that there will be approximately an additional 8 million installed. IEPFR Consultation DCC Public Page 11 of 144

12 The Government believes that there are important shared benefits from the enrolment of SMETS1 meters with DCC. In particular, this will enable more efficient and effective switching for customers due to the retention of smart meter functionality and should reduce the risk of these meters being replaced before the end of their operating lives. This report sets out a feasibility stage assessment of the key technical, commercial, implementation and other associated aspects required to deliver a DCC SMETS1service including the enrolment of SMETS1 devices. 2.4 About the document Section N of the SEC requires DCC to produce a feasibility report, the IEPFR, for the delivery of a DCC SMETS1 meter enrolment capability and to submit this report to the Secretary of State. Section N4.5 of the SEC states: Before submitting the Initial Enrolment Project Feasibility Report to the Secretary of State, the DCC shall produce a draft report and consult with the Panel, the Parties and other interested persons concerning the content of such draft. This document has been developed by DCC to enable DCC to fulfil the requirement to consult on the draft IEPFR. It sets out the current view of the technical, commercial and implementation options available. In order to assess areas of optionality, the report identifies a set of criteria against which options can be assessed. Appendix C to this report contains an explanation of the relevant assessment criteria for each area of optionality. The information presented in this draft report has been developed over the last 16 months with the input and support from a range of SEC parties and other stakeholders. Consistent with section N of the SEC, the term adoption is used in this draft report to describe the process of novation (with amendment) of the existing arrangements that energy suppliers have in place for SMETS1 communication services. The term novation is used in this draft report to describe the process of novation (with amendment) of the existing arrangements that energy suppliers have in place for SMETS1 data services. DCC has included, within each section of this document, a series of consultation questions (summarised in Appendix B) through which DCC is inviting industry input on various elements of the analysis including the options DCC has identified, the assessment of these options and the proposed implementation approach. DCC will be using responses to this consultation to update the IEPFR, prior to submission to the Secretary of State early next year. Alongside the IEPFR, section N4.6 of the SEC requires DCC to submit to the Secretary of State copies of all consultation responses received and a commentary on how consultation responses have been addressed. DCC has provided appropriate opportunities for those Supplier Parties included in the scope of the IEFPR to notify DCC if they wish to include any additional Energy Meters, or exclude some or all their Energy Meters from the scope of the IEPFR, prior to consultation. Where appropriate, DCC will continue to provide these opportunities during the development of the project. IEPFR Consultation DCC Public Page 12 of 144

13 3 Technical Options 3.1 Introduction In this section of the report DCC presents and analyses four aspects of the technical solution required to deliver a DCC SMETS1 Service: Integration path: options for the means by which DCC can communicate with SMETS1 meters to enable their enrolment and subsequently send commands to, and receive messages from, enrolled SMETS1 meters; SMETS1 DCC user interface: options for the means by which users can communicate with DCC to enable suppliers to enrol SMETS1 meters with DCC and to enable all users to send service requests to, and receive service responses from, enrolled SMETS1 meters; Communication services: options for the range of SMETS1 communication services (service requests) that are available to users for DCC enrolled SMETS1 meters; and Prepayment: options to support the generation of UTRNs for use with DCC enrolled SMETS1 meters operating in prepayment mode and the process for sending over the air top up requests to SMETS1 prepayment meters. For each of the four areas the report identifies a range of options and considers the feasibility of each option, including a comparative analysis against the assessment criteria outlined in Appendix C. The report then summarises the key conclusions and asks a set of consultation questions about whether consultation respondents agree with the identification and analysis of the options. 3.2 Integration Path Options Context In order to provide a DCC SMETS1 Service, DCC needs to establish communication with SMETS1 meters such that (on an on-going basis) DCC can provide the SMETS1 communication services in respect of the SMETS1 meter. There are a number of options for how DCC might technically communicate (via integration) with a SMETS1 meter, which are set out and evaluated below. Integration path is the term that is used to describe how such communications might take place Requirement Figure 1 sets out a high level representation of the key components of the technical infrastructure that currently supports both SMETS1 and SMETS2 meters. In both cases, meters and communications hubs connect through a communications network to a data service which is then accessed by users. Conceptually it is possible to make changes to or between any one of these components of the technical infrastructure in order to enable DCC communications with the SMETS1 meter. IEPFR Consultation DCC Public Page 13 of 144

14 SMETS2 Comms Hub SMETS2 CSP SMETS2 DSP DCC User Interface SMETS1 Comms Hub SMETS1 CSP SMSO SMET2 DCC Users SMETS1 Comms Hub SMETS2 Path SMETS1 Path SMETS1 CSP SMSO SMETS1 Users Figure 1 Key technical components in the current landscape for SMETS1 and SMETS2 meters Options Summary The integration path options have been generated based on an analysis of each of the following key components of the technical infrastructures: meter technology: an analysis of the functionality and capability of SMETS1 meters within the scope of the report, and the potential for changing this, with a view to ascertaining how communications could take place; communication hub/communications network: an analysis of the functionality and capability of communications infrastructure for the SMETS1 meters within the scope of the report, and the potential for changing this, to identify the options for integrating with existing or different communications networks; and data services: an analysis of options for: a new system provided by DCC that prepares and processes communications to be sent to/received from SMETS1 meters (a new SMETS1 DSP providing a new head end systems (HES)); and the suitability of using existing systems (i.e. SMSO HES s) for integration within the DCC SMETS1 infrastructure, including compatibility. 1 Number of SMSOs in diagram is purely indicative. IEPFR Consultation DCC Public Page 14 of 144

15 This initial analysis resulted in five possible integration path options. Three of the options involve reuse of the SMETS2 CSP and SMETS2 DSP technical infrastructure while a further two implement a parallel and dedicated SMETS1 technical infrastructure. The integration path options are explained below, but in summary they are: Integration Path 1: Install SMETS2 communications hub and upgrade SMETS1 meter to enable GBCS communications via SMETS2 DSP and SMETS2 CSPs; Integration Path 2: Install modified SMETS2 communications hub to enable communications via SMETS2 CSPs and a SMETS1 DSP; Integration Path 3: Adapt and alter SMETS1 communications hub to enable communication via SMETS2 CSPs and a SMETS1 DSP; Integration Path 4: Create a new SMETS1 data services capability to directly integrate to existing SMETS1 CSPs and existing SMETS1 meters ( integrate to meter ); and Integration Path 5: Use existing SMETS1 data services capability, SMSO which integrates to existing SMETS1 CSPs and existing SMETS1 meters ( integrate to SMSO ). Integration Path 1: Install SMETS2 communications hub and upgrade SMETS1 meter to enable GBCS communications via SMETS2 DSP and SMETS2 CSPs For the first integration path option, DCC has investigated the potential to replace the SMETS1 communications hubs with SMETS2 communications hubs in order to enable connection through the SMETS2 CSPs and to the SMETS2 DSP. In this option firmware upgrades are applied to the SMETS1 meter to allow it to communicate using GBCS through the existing SMETS2 infrastructure when enrolled, without the need for any changes to DCC Systems. 1 SMETS1 Comms Hub SMETS2 Comms Hub DCC SMETS1 User FIRMWARE UPDATE SMETS2 CSP SMETS2 DSP Figure 2 Integration Path Option 1 Upon analysis, DCC does not consider this integration path to be an appropriate option to consider in more detail as: it would require a site visit to replace the existing communications hub with a SMETS2 communications hub. DCC considers the cost implications of a site visit make this IEPFR Consultation DCC Public Page 15 of 144

16 option materially more expensive than other feasible options due to the related labour and replacement equipment costs; and it will be technically more risky than integration path options 4 and 5 due to the complex nature of the technical solution required. It requires the SMETS1 meter to understand the language of SMETS2 GBCS, which is technically more challenging than other integration path options. In addition there is the risk that the SMETS2 communications hub and the SMETS1 meter might not be compatible. Integration path option 1 has therefore been discounted at this stage. Integration Path 2: Install modified SMETS2 communications hub to enable communications via SMETS2 CSPs and a SMETS1 DSP The second integration path option also considers the potential to replace the SMETS1 communications hubs in order to enable connection through the SMETS2 CSPs. In this instance a modified SMETS2 communication hub is installed, to enable connection to the SMETS2 CSP communications network. The installed device would not be a SMETS2 communications hub as changes would be needed to enable it to communicate with the SMETS1 meters. The SMETS1 meters would continue to communicate in their native language, therefore no firmware upgrades are applied to the SMETS1 meters. Instead the SMETS2 CSP will pass messages from the SMETS1 meter in its native SMETS1 commands to a SMETS1 DSP (which could be a new SMETS1 DSP or the existing SMETS2 DSP augmented with additional functionality to support SMETS1 commands and security controls). 2 DCC SMETS1 SMETS1 Comms Hub SMETS2 Compatible CH SMETS2 CSP SMETS1 DSP User Figure 3 Integration Path Option 2 Upon analysis, DCC does not consider this integration path to be an appropriate option either as: it would require a site visit to replace the existing communications hub with a modified SMETS2 communications hub. DCC considers the cost implications of a site visit make this option materially more expensive than other feasible options due to the related labour and replacement equipment costs; and it would be technically more risky than integration path options 4 and 5 as it would require the modified SMET2 communications hub to be able to communicate effectively with the SMETS1 meter, when it was not originally designed for this purpose. Integration path option 2 has therefore also been discounted at this stage. IEPFR Consultation DCC Public Page 16 of 144

17 Integration Path 3: Adapt and alter SMETS1 communications hub to enable communication via SMETS2 CSPs and a SMETS1 DSP The third integration path option considers the potential to make changes to the existing SMETS1 communications hubs in order to enable communications to be supported by the SMETS2 CSPs. In this option the communications hub is physically adapted to include a radio (for premises in the North Region) and to replace the SIM (for premises in all Regions). Additionally the SMETS1 meter firmware is upgraded to enable SMETS1 meters to communicate through SMETS2 CSPs (albeit still using native SMETS1 commands). 3 SMETS1 Comms Hub ADAPT SMETS1 Comms Hub DCC SMETS1 User FIRMWARE UPDATE SMETS2 CSP SMETS1 DSP Figure 4 Integration Path Option 3 Upon analysis, DCC does not consider this integration path to be an appropriate option either as: it would require a site visit to adapt the existing equipment on-site. DCC considers the cost implications of a site visit make this option materially more expensive than other feasible options due to the related labour and replacement equipment costs; and it is technically more risky than integration path options 4 and 5 as uncertainty exists over how effectively the existing SMETS1 meter could actually be adapted under this option. Adapting the equipment could introduces further issues associated with the performance of the equipment, the need for re-testing of the equipment etc. Integration path option 3 has therefore been discounted at this stage. Integration Path 4: Create a new SMETS1 data services capability to directly integrate to existing SMETS1 CSPs and existing SMETS1 meters ( integrate to meter ) The fourth integration path uses existing SMETS1 meters, communications hubs and SMETS1 CSPs. The incumbent SMSOs would be replaced and DCC would procure a new SMETS1 data services capability that includes the provision of a HES that would communicate directly with SMETS1 meters over the existing SMETS1 CSP networks using existing communications hubs. IEPFR Consultation DCC Public Page 17 of 144

18 SMETS1 Capabilities 4 New SMETS1 Data Services DCC SMETS1 SMETS1 Comms Hub SMETS1 CSP Translate Request Manager Comms Manager User Figure 5 Integration Path Option 4 For integration path option 4 ( integrate to meter ), the following components would form part of a new DCC procured data service: request management function a request management function that would process service requests received over the SMETS1 DCC user interface and service responses to be returned over the SMETS1 DCC user interface, including the validation of requests, associating them with the relevant SMETS1 meter and associating service responses received from the SMETS1 meter with the relevant user; translate function that would convert service requests received over the DCC user interface into commands in the meter s native language; and communications manager that establishes communications with the meter s communications hub prior to sending the command to the meter. Under this option new interfaces would need to be established between the new SMETS1 DSP and the existing SMETS1 CSPs. The technical feasibility of this option has been explored through DCC s Enrolment Options Testing (EOT) project (see Appendix G for detail) with the meter cohorts that participated in this aspect of the project. EOT comprised a technical research project investigating the integration of SMETS1 meters with DCC. EOT demonstrated that the proposed approach is technically feasible. It also showed that there was a closer alignment between the DUIS-type service requests selected for testing and the meter cohort command sets under test than there was between the DUIS-type service requests and corresponding messages that would have to be sent to the SMSO-user interfaces that supported the same meter cohorts (were integration path option 5 to be adopted). DCC believes that this is because the meter cohort command sets have been developed in line with a common specification (SMETS1), whereas the SMSO-user interfaces have been developed in accordance with the business requirements of the individual suppliers interfacing with that SMSO. These business requirements do not always have a one-toone mapping to the SMETS1 suite of interface commands. The fact that there was closer alignment between the DUIS-type service requests and the meter commands implies that this integration path option might present fewer technical challenges in this regard than integration path option 5. IEPFR Consultation DCC Public Page 18 of 144

19 Integration Path 5: Use existing SMETS1 data services capability (the SMSO), which integrates to existing SMETS1 CSPs and existing SMETS1 Meters ( integrate to SMSO ) The fifth integration path also uses existing SMETS1 meters, communications hubs and SMETS1 CSPs but also uses existing SMETS1 SMSOs (together with their existing HESs). This option would involve the service request sent to DCC by a user, a user service request (formats for which are discussed in section 3.3), being converted into an SMSO service request (in the format of the current SMSO-user interface/language). As with the current arrangements, the SMSO would then convert the SMSO service request into a command to be sent to the meter. As with Option 4, DCC would need to procure new data services that include request management functions, but in this instance associating service requests and responses with the correct SMSOs and users. The analysis has shown that there may not be a direct one-to-one mapping between the user service request and the SMSO service request, so DCC expect that this request management function may need to take a single user service request and map it to multiple SMSO service requests. As with the current arrangements, the SMSO would use their communications manager to establish communications with the meter s communications hub prior to sending commands to the meter. Options exist for the design of the DCC SMSO interface as follows: non-standardised DCC - SMSO interface: the existing SMSO interfaces are retained and DCC procures the service that would translate user service requests into SMSO service requests; or standardised DCC - SMSO interface: DCC contracts with SMSOs to modify their interfaces to provide the function to translate the user service requests into the SMSO service requests. SMETS1 Capabilities 5 A New SMETS1 Data Services DCC SMETS1 SMETS1 Comms Hub SMETS1 CSP SMSO Translate Request Manager Comms Manager User 5 B New SMETS1 Data Services DCC SMETS1 SMETS1 Comms Hub SMETS1 CSP SMSO Translate Request Manager Comms Manager User Figure 6 Integration Path Option 5a and 5b The analysis has identified that option 5 is technically feasible for all meter cohorts proposed for inclusion in the IEPFR. However EOT test results have also indicated that, IEPFR Consultation DCC Public Page 19 of 144

20 as is to be expected, there is a longer response time when routing messages via existing SMSOs as opposed to routing messages via a new SMETS1 DSP ( integrate to meter ). This is due to an additional step being required in the technical solution for option 5 which requires the conversion of user service requests into SMSO service requests prior to conversion into meter commands. At this stage it is not possible to quantify the additional response time associated with option 5. The only data that exists is that from EOT which cannot be relied upon as providing an accurate indication of response times, as the environments used were test environments. The next phase of analysis will improve the understanding of the likely impact. Other options that have been discounted In addition to considering integrating complete SMSO solutions as set out in option 5, initial thoughts were given to incorporating only certain components of SMSO systems (such as the communications managers of SMSOs). This would represent a hybrid approach where certain functions of the existing SMSO systems are used and another new SMETS1 DSP is used for other functions that the SMSO currently undertakes. However, it was apparent that there were considerable disadvantages to this approach as the current HES solutions provided by existing SMSOs have not been constructed in a modular way. This makes it difficult to identify and isolate specific functions within the overall solution and makes it difficult to create new interfaces that integrate at any point other than the originally designed external interface of the HES. To attempt integrating at other points expose additional risk because: further development by SMSOs would be required to integrate at points within their systems that have not been designed to be exposed; the software packages were not designed in this way, therefore introducing new code to enable direct interface to lower level functionality has the potential to break the whole package which could destabilise the software and introduce more unexpected issues. This would lead to a substantive delivery risk and reduced confidence in the solution; and experience through EOT indicates that original designers, architects and developers may not be available and the level of documentation of the solutions is variable. Solutions vary according to specific requirements and even though the functionality is understood, the code which drives that functionality may not be so clear or well documented. This may lead to unexpected issues and bugs, extending the development and testing phase. For these reasons, options have not been included in the IEPFR which build on this approach. In summary, integration path options 4, 5a and 5b have been taken forward for further evaluation Evaluation against Criteria Table 1 below contains an evaluation of integration path options 4 and 5 against criteria defined in Appendix C. IEPFR Consultation DCC Public Page 20 of 144

21 Criteria Integration Path Option 4 ( integrate to meter ) Integration Path Option 5A ( integrate to SMSO ) Integration Path Option 5B ( integrate to SMSO ) Enrolment Service Costs Lower Higher Higher Costs are estimated to range between 130m - 420m. The above costs include costs for communications, SMSOs and integration option specific build and application support. It should be noted that the costs of the Integration Path Options are a combination of new costs and existing costs that are already being incurred by Energy Suppliers. Under Adoption and Enrolment, these existing costs would then be borne by the DCC, specifically costs incurred under SMSO (if integration path 5 is chosen) and SMETS1 CSP contracts. DCC expects that where translation is developed centrally (Option 5a) that whole life enrolment service costs could be marginally lower than where multiple industry providers develop translation. The impact of this will be quantified through the design phase of the programme. Delivery Timescales Slower Faster (there is no difference in delivery timescales between integration path option 5a and 5b). Technical Delivery Confidence All options have a high technical delivery confidence based on technical feasibility demonstrated through EOT testing (see Appendix G). One new HES reduces technical delivery risk (rather than multiple SMSO HESs). New functionality (provided through the new SMETS1 DSP) will be required to convert user service requests to meter commands, increasing technical delivery risk. Additionally new interfaces will need to be established between the new SMETS1 DSP and existing SMETS1 CSPs, so whilst increasing technical delivery risk these interfaces are established and well documented. Changes to SMSO interfaces are required. Multiple SMSO HESs integrating with a single DCC interface increases delivery risk (in comparison to using one HES). Established functionality is utilised to convert SMSO service request to meter commands, which reduces technical delivery risk. However new functionality is required to convert user service requests to SMSO service requests. Established interfaces are utilised between existing SMSOs and SMETS1 CSPs, which reduces technical delivery risk. EOT showed that meter command sets map more closely to DUIS which means that technical integration might be more straightforward under this option. Mapping of DUIS to each SMSO-user interface might make technical integration more challenging due to lower level of alignment as compared to option 4 ( integrate to meter ). Functionality The integration path option chosen does not affect the functionality that DCC is able to provide to users in terms of the SMETS1 DCC user interface and SMETS1 IEPFR Consultation DCC Public Page 21 of 144

22 Criteria Integration Path Option 4 ( integrate to meter ) Integration Path Option 5A ( integrate to SMSO ) Integration Path Option 5B ( integrate to SMSO ) communication services. In integration path option 5 triaging and resolution of incidents could potentially take longer due to more service providers in the contractual chain as compared to option 4; however DCC does not consider that this should be the dominant factor in choosing between the options. Impact on existing arrangements All options reuse SMETS1 meters and communication hubs without changes to them. Utilises existing SMETS1 CSP contracts, subject to successful adoption. Does not use existing SMSOs. Utilises existing SMETS1 CSP and SMSO contracts, subject to successful adoption/novation. Some development work is required by SMSOs in order to integrate with the new SMETS1 DSP. A higher level of development work is required by SMSOs as compared to option 5a, in order to provide translation layer and integrate with the new SMETS1 DSP. Table 1 Integration Path Options 4 and 5 Evaluation Conclusions Options 4, 5a and 5b are all technically feasible integration path options. Options 4, 5a and 5b will be considered as part of the commercial and implementation analysis in later sections of this report Consultation Questions Consultation Questions: Integration Path options 1 Do you agree with the range of integration path options that DCC has considered, or do you consider that there are other integration path options that should be considered? Please provide a rationale for your views. 2 Do you agree that integration path options 1-3 should not be progressed on the grounds of cost and technical risk? Please provide a rationale for your views. 3 Do you agree with the analysis of the relative advantages and disadvantages of integration path options 4 ( integrate to meter ) and 5 ( integrate to SMSO )? Please provide any other views on the relative advantages and disadvantages of integration path options 4 and 5. Please provide a rationale for your views. 4 Please provide views on whether, within option 5 ( integrate to SMSO ), 5a or 5b is preferable. Please provide a rationale for your views. IEPFR Consultation DCC Public Page 22 of 144

23 3.3 SMETS1 DCC User Interface Options Context Suppliers currently communicate with their SMETS1 meters via an SMSO-user interface (whether that SMSO service is something that has been developed in-house or externally procured). This means that thirteen suppliers communicate with one or more SMSOs over six separate user interfaces. Where SMETS1 meters are enrolled with DCC, communications by suppliers with SMETS1 meters would take place via a single SMETS1 DCC user interface. It is the provision under the SEC of this single interface that enables SMETS1 meters to remain operable where a customer with a SMETS1 meter switches suppliers. Additionally this interface would enable network operators and other users to communicate with DCC enrolled SMETS1 meters. This section considers technical options for the SMETS1 DCC user interface ( SMETS1 DCC user interface options ) Requirement In relation to SMETS1 DCC user interface options, section N4.4 of the SEC requires that as part of the IEFPR, DCC undertakes an analysis of: the means by which DCC will provide SMETS1 Services in respect of the Eligible Meters such that (insofar as reasonably practicable) users may send service requests and receive service responses in respect of those communication services via the DCC user interface (such that the format of communications over the DCC user interface in relation to each SMETS1 Service is the same as that for existing equivalent DCC user interface services); and where it better facilitates achievement of the SEC objectives, the provision by DCC to users of the SMETS1 Services in respect of the Eligible Meters by another means than that referred to in (a) above. In line with the above requirement, in this section DCC will consider options for a SMETS1 DCC user interface that most closely approximates the existing DCC user interface for SMETS2 meters. Additionally DCC considers other SMETS1 DCC user interface options and assesses whether those options would better facilitate achievement of the SEC objectives Options Summary The options presented in this section have been developed based on a consideration of: The format for messages sent across a SMETS1 DCC user interface. Options considered are a SMETS2 DUIS style format or a new format developed for SMETS1 meters; and The provision of the SMETS1 DCC user interface. Options considered are a SMETS2 DSP-hosted interface via the DCC User Gateway (so using the same technology as supports SMETS2 meters) or a new hosting service which is competitively procured. This analysis has resulted in three potential SMETS1 DCC user interface options: IEPFR Consultation DCC Public Page 23 of 144

24 option 1: Message format based on SMETS2 DUIS utilising the existing interface provided by the SMETS2 DSP. The DUIS would need to be amended where necessary to support communication with SMETS1 devices; option 2: Message format based on the SMETS2 DUIS (amended where necessary) but with the interface provision competitively procured (so rules for connecting to the interface would potentially differ to those in the SMETS2 DUIS); or option 3: New SMETS1 message format with the interface provision competitively procured (so no commonality with the SMETS2 DUIS). The other possible combination is that of a SMETS2 DSP hosted interface based on a new SMETS1 message format. However parties other than the SMETS2 DSP would be capable of hosting this interface. This option was therefore discounted as it was not considered appropriate to assume SMETS2 DSP hosting with a new SMETS1 message format without undertaking a competitive procurement activity for the hosting of this interface. For the purposes of SMETS1 DCC user interface options analysis it has been assumed that whoever hosts the SMETS1 DCC user interface will also provide the connection to that interface. DCC understands that security concerns would arise were a non-dsp procured connection to be used to connect to the DSP systems Analysis of Options SMETS1 DCC user interface Option 1: SMETS2 DUIS message format (amended where necessary) utilising the existing interface provided by SMETS2 DSP As shown in Figure 7 below, this option would involve DCC users connecting to the SMETS2 DSP for the purpose of communicating with DCC enrolled SMETS1 meters. Consequently existing DCC Gateway connections used to communicate with SMETS2 meters would be capable of being used, subject to the user satisfying itself that it has sufficient connection capacity. SMETS1 service requests sent by DCC users would be formatted in accordance with the DCC User Interface Specification (DUIS) as set out in the SEC. However the DUIS message structures/formats ( schema ) may need to be amended to accommodate SMETS1 Meters, for example to: change some of the allowable values for some data items; change some validation rules for certain service requests so that some data items are not mandatory for a SMETS1 service request; include some SMETS1 specific data items for some service requests; add a SMETS1 version tag; and add SMETS1 specific error response codes to account for differences in SMETS1 technology. IEPFR Consultation DCC Public Page 24 of 144

25 SMETS1 service requests would be routed by the SMETS2 DSP to the SMETS1 request management function (subsequently referred to in this section as the new SMETS1 DSP ). Ui1 SMETS1 Comms Hub SMETS1 DSP SMET2 DSP DCC User Interface DUIS Format Request / Response DCC SMETS1 Users Figure 7 Summary of User Interface Option 1 Under this option, as both SMETS1 and SMETS2 service requests will be routed through the SMETS2 DSP, the target device for the service request will need to be identified as either a SMETS1 or SMETS2 meter. This identification is likely to be carried out by the SMETS2 DSP when the service request is received, by checking the device ID against the smart metering inventory. In the case of SMETS1 meters, the SMETS2 DSP would then route the message to the new SMETS1 DSP. SMETS1 DCC user interface Option 2: SMETS2 DUIS message format (amended where necessary) with interface provision competitively procured As shown in Figure 8 below, this option would create message format/structures based on SMETS2 DUIS service requests; however a different interface would be connected to via a new network connection for the purpose of sending SMETS1 service requests and receiving SMETS1 responses. Ui2 SMETS1 Comms Hub SMETS1 DSP NEW DCC User Interface SMETS1 DUIS Format Request / Response DCC SMETS1 Users Figure 8 Summary of User Interface Option 2 The structure of the schema for SMETS1 service requests would be similar to the DUIS, however as is the case under option 1, it might require adaptation to accommodate SMETS1 meters. New rules would need to be developed for connecting to the SMETS1 interface. As a new connection to a new interface would be provided under this option, new security controls (which could be very similar to existing controls) would have to be applied to secure the communications, and new anomaly detection controls would need to be put in place. IEPFR Consultation DCC Public Page 25 of 144

26 A new service to host the connection and route messages to the new SMETS1 DSP would be procured (noting that depending upon the approach to structuring lots for the procurement of new services, this service might be bundled with the new SMETS1 DSP function). Under this option there would be a similar format between SMETS1 and SMETS2 service requests. Consequently the user would have to identify in advance whether it was sending the service request to a SMETS1 meter or a SMETS2 meter, as it would need to know which interface to connect to for the purpose of sending the service request. SMETS1 DCC user interface Option 3: A new SMETS1 message format with interface provision competitively procured As shown in Figure 9 below, this option would create a newly hosted SMETS1 DCC user interface using a new message format for SMETS1 service requests. The process for connecting to the interface and the schema for sending SMETS1 service requests would be contained in a new SMETS1 DCC user interface specification. Ui3 SMETS1 Comms Hub SMETS1 DSP NEW DCC User Interface New Format Request / Response DCC SMETS1 Users Figure 9 Summary of User Interface Option 3 As with option 2, given that a new connection to a new interface would be provided, new security controls would have to be applied to secure the communications and new anomaly detection controls would need to be put in place. Again as with option 2, a new service to host the connection and route messages to the new SMETS1 DSP would be procured (noting that depending upon the approach to structuring lots for the procurement of new services, this service might be bundled with the new SMETS1 DSP function) Evaluation against Criteria Table 2 below contains an evaluation of DCC user interface options against the criteria defined in Appendix C. Criteria SMETS1 DCC User Interface Option 1 SMETS1 DCC User Interface Option 2 SMETS1 DCC User Interface Option 3 Enrolment Service Costs Lowest Higher than option 1 but lower than option 3. Highest Costs are estimated to range between 10m - 120m. The cost for user interface technical options is dependent upon the level of development effort required for each option. Delivery The provision of a SMETS1 DCC user interface is not on the critical path for IEPFR Consultation DCC Public Page 26 of 144

27 Criteria SMETS1 DCC User Interface Option 1 SMETS1 DCC User Interface Option 2 SMETS1 DCC User Interface Option 3 Timescales delivery. The delivery timescales for each of these options will be developed in the design phase of the programme, as appropriate. Technical Delivery Confidence High technical delivery confidence as extending existing SMETS2 service. By reusing the SMETS2 DSP, existing security controls across the DCC user interface can be used to support the SMETS1 solution, including use of the DCC Key Infrastructure (DCCKI). See section 4 for more details of the security model. High/medium technical delivery confidence as this option re-uses SMETS2 message structures but applies them across a different interface. Due to the desire for commonality between the message structures, this option would have to ensure that any changes to the schema for SMETS2 are mirrored in the schema for SMETS1. The security controls that exist in the SMETS2 DSP solution would be mirrored in the new solution also. For example the new organisation hosting the interface would need to implement a public key infrastructure (PKI) solution to support communications across that interface. Testing requirements are likely to be higher than option 1, as both new interface and new service requests need to be tested whereas in option 1 only the new service requests need to be tested. Medium technical delivery confidence as this option requires the definition of a new interface schema and a new interface. This option will require the most extensive development and testing as compared to the other two options. This interface achieves logical and physical separation between the SMETS1 user interface and DCC user interface which is arguably preferable from a security perspective. This interface achieves logical and physical separation between the SMETS1 user interface and DCC user interface which is arguably preferable from a security perspective to only logical separation. Functionality The SMETS1 DCC user interface option does not affect the communication services that can be provided over that interface. Given that the DCC SMETS1 Service would IEPFR Consultation DCC Public Page 27 of 144

28 Criteria SMETS1 DCC User Interface Option 1 SMETS1 DCC User Interface Option 2 SMETS1 DCC User Interface Option 3 be hosted by the SMETS2 DSP, there is the potential for this interface option to impact on the SMETS2 DSP performance in relation to SMETS2. This risk would be mitigated by adequately scaling infrastructure. An assumed cost of this scaling is included in DCC contingency costs. Impact on Users Message format: reuse of SMETS2 Service Requests provides greater consistency of functionality between SMETS1 and SMETS2 compared to option 3. Users of the SMETS1 Service will need to modify their systems to accommodate any changes to the DUIS schema. Hosting of interface: by reusing the SMETS2 DSP interface DCC consider that the amount of change to the user s own systems to interface with DCC systems would be minimised. User systems would be able to generate service requests without having to identify whether they are to be sent to the SMETS1 or SMETS2 interface. Message format: as per Option 1. Hosting of interface: SMETS1 Service requests would have to be identified by the User to enable routing to the SMETS1 DCC User interface. Additional business processes would be required to support this. Network connection: with a new network connection, the user would potentially need new networking equipment added to their premises and would need to make changes to their systems to enable them to direct communications to the new DCC SMETS1 interface. Message format: This option does not reuse the SMETS2 message format but creates a new SMETS1 message format, so will have a higher impact on users than options 1 and 2. Hosting of interface: SMETS1 service requests would be sufficiently distinct from SMETS2 Service Requests and would be routed to the SMETS1 DCC user interface. Additional business processes would be required to support this. Network connection: as per Option 2. Network connection: assuming that the user has procured sufficient capacity, there would only be the one DCC Gateway connection for both SMETS2 and SMETS1. Table 2 SMETS1 DCC User Interface Options Evaluation IEPFR Consultation DCC Public Page 28 of 144

29 3.3.6 Evaluation of Options 2 and 3 against SEC objectives As set out in 3.3.2, the SEC requires that SMETS1 DCC user interface options that do not involve the sending of service requests to SMETS1 meters across the DCC user interface and in the format set out in the DUIS should be considered where such options would better facilitate achievement of the SEC objectives. Initial analysis against the SEC objectives indicates that option 1 is more efficient for DCC to implement, however in order to conclude that it is more efficient overall, DCC user costs also need to be taken into account and a change request would need to be progressed with the SMETS2 DSP. Options 2 and 3 might arguably be better when considering security controls; however DCC considers that the requisite level of security can be secured under option 1 also. Depending upon the length of time taken to deliver changes to the SMETS2 DSP system under option 1, options 2 and 3 might be faster to implement. At the current time, it is not therefore possible to conclude whether either of options 2 or 3 better facilitates achievement of the SEC objectives. To aid in reaching a conclusion in the IEFPR to be submitted to the Secretary of State, DCC is seeking views in the consultation questions below Conclusions All three SMETS1 DCC user interface options are compatible with the integration path Options 4 and 5 set out in the previous section. Technically all of the SMETS1 DCC user interface options identified are feasible. It is not yet possible for DCC to conclude whether either of options 2 or 3 might better facilitate achievement of the SEC objectives Consultation Questions Consultation Questions: SMETS1 DCC user interface options 5 Do you agree with the range of SMETS1 DCC user interface options that DCC has considered, or do you consider that there are other options that should be evaluated? Please provide a rationale for your views. 6 Do you agree with the analysis of the relative advantages and disadvantages of each of the SMETS1 DCC user interface options? Please provide a rationale for your views. 7 Please tell us which SMETS1 DCC user interface option you consider to be preferable. Please provide a rationale for your views. 8 Please provide your views on whether either SMETS1 DCC user interface option 2 or 3 better facilitates achievement of the SEC Objectives than SMETS1 DCC user interface Option 1. Please provide a rationale for your views. IEPFR Consultation DCC Public Page 29 of 144

30 3.4 Service Request Functionality: Communication Services Options Context As part of a DCC SMETS1 Service, DCC would provide a specified set of communication services for DCC enrolled SMETS1 meters ( the SMETS1 Communication Services ). These SMETS1 Communication Services would include a core DCC offering. Options exist for the communication services that form part of the core DCC offering ( core communication services ). Options also exist for the provision of additional communication services above this core offering, on a bespoke/bilateral basis ( elective communication services ). In respect of SMETS1 Communication Services, the SEC currently includes requirements as follows: N2.2 Upon Enrolment of any SMETS1 Meter, the communication services that the DCC provides in relation to those meters must include (as a minimum) the ability, for those Users identified as eligible to do so, to send Service Requests to those meters requesting the Minimum SMETS1 Services. N2.3 The detail of the SMETS1 Services will be established in the amendments to this Code produced pursuant to the Initial Enrolment Project Feasibility Report or any subsequent Modification Proposal. The Minimum SMETS1 Communication Services are listed in Appendix F to the SEC and comprise 37 services. This list is also included in Appendix D. In section N4.4 of the SEC, it states that DCC shall include within the IEPFR: h. options for amendment of the Minimum SMETS1 Services such that DCC can provide additional Services to Parties which are equivalent to the DCC User Interface Services; All suppliers that responded to DCC's Invitation confirmed that all the meters they proposed for inclusion in the scope of the IEPFR are Eligible Meters, that is, each meter is: either a SMETS1 meter or subject to an upgrade plan which will result in it being a SMETS1 meter prior to its enrolment; or installed at premises (or planned to be installed at premises) for which the supplier party that proposes the meter is an energy supplier (SEC N1.1). Given this response, it follows that all of the meters included in the scope of the IEPFR will be capable of supporting all of the Minimum SMETS1 Services by the time of enrolment. As part of the responses to DCC's Invitation, suppliers listed a number of additional communication services that are currently supported for one or more meter cohorts but not included in the Minimum SMETS1 Communication Services. Suppliers also identified some further communication services that are not currently supported for any meter IEPFR Consultation DCC Public Page 30 of 144

31 cohort, but that they considered would be necessary as part of the core offering for DCC enrolled SMETS1 meters, based on their analysis of DUIS. For DCC enrolled SMETS2 meters, the SEC already includes the concept of core and elective communication services. Core services (as defined in appendix E of the SEC) are those services that are generally available in relation to enrolled smart metering systems, depending upon User Role. Elective communication services are services that are provided to a particular user upon request under the terms of a supplemental bilateral agreement with DCC, and which remain confidential for a period of time (the proforma for this supplemental agreement is in Schedule 3 of the SEC). Elective communication services do not, therefore, form part of the core service offering (unless the SEC is subsequently amended to make them so). Costs associated with the provision of elective communication services would be determined in accordance with the provisions of section H7 of the SEC. DCC considers that as part of the DCC SMETS1 Service, any services in excess of the core DCC offering that are in use by suppliers could be provided as elective communication services, such that suppliers will not lose access to those services upon enrolment of their SMETS1 meter with DCC. DCC recognises that SMSO services continue to evolve and the catalogue of additional services to be included as elective communication services for go-live of the DCC SMETS1 Service would need to be determined at an appropriate point during the transition from feasibility stage to implementation of the DCC enrolment project. In summary therefore, the DCC SMETS1 communication services could comprise the following components: 1. The core communication services which could include: the minimum 37 services identified in appendix D or any of the other options set out in below, plus; the additional services that DCC considers would be required to support a SMETS1 Service, set out in section 3.4.6, and 2. Elective communication services being any other communication services that are in use by and are still required by suppliers but that are not provided as core communication services. DCC has not included a list of these services and the SMSOs that offer them in this draft report due to commercial sensitivity, but will provide this information to BEIS. The remainder of this section focusses on the options available for 1a) above in relation to DCC enrolled SMETS1 meters and the assessment of those options against the criteria described in Appendix C Options Summary The options presented in this section for 1a) above take as a baseline the provision of the 37 Minimum SMETS1 Services outlined in Appendix F to the SEC. In identifying other options DCC looked at the services currently available from SMSOs to understand the current level of alignment with the Minimum SMETS1 Communication Services and to identify commonalities. This gave rise to the following considerations: whether options should include the provision of a sub-set of the Minimum SMETS1 Services, either with or without prepayment functionality; and IEPFR Consultation DCC Public Page 31 of 144

32 whether options should include the provision of a standardised set of core communication services in respect of all DCC enrolled SMETS1 meters or whether the service offering would vary per SMETS1 meter cohort. This analysis has resulted in six potential communication service options as follows: Option1 - DCC provides the Minimum SMETS1 Services (37 Services) for all DCC enrolled SMETS1 meters the base case; Option 2 - DCC provides less than the minimum 37, that being SMETS1 Services that comprise the lowest common denominator among all SMSOs (this would amount to 7 Services); Option 3 - DCC provides less than the minimum 37, that being SMETS1 Services that comprise the lowest common denominator among SMSOs plus a functioning prepayment solution (7 + 5 Services). This option does not therefore offer the full range of prepayment services that are currently available in relation to some meter cohorts, instead it delivers the minimum prepayment services required for prepayment arrangements to operate; Option 4 - DCC provides less than the minimum 37, that being SMETS1 Services that comprise the lowest common denominator among all SMSOs plus the as-is prepayment services specific to each SMSO (7 + n Services). This would result in the withdrawal from the core service offering of some of the services that SMSOs currently provide, that being those services that are not commonly offered across all SMSOs that do not relate to prepayment functionality; Option 5 - DCC provides the as-is services currently supported by each SMSO (n Services), which in some cases would result in less than the minimum 37: based on analysis of the information provided to DCC by suppliers, the extent of support by SMSOs for the Minimum SMETS1 Services varies widely; in relation to prepayment functionality, approximately 4% of the projected SMETS1 meter population is operated by SMSOs that do not offer such functionality and therefore could not be used in prepayment mode under this option without further changes later to the SEC and systems; this option may require supplier and network operator users to operate separate business processes specific to each type of DCC enrolled SMETS1 meter in its estate, where DCC provides a different set of SMETS1 Services for those meter types; and Option 6 - DCC provides the as-is services (as per option 5 above) when the DCC SMETS1 capability goes live, with a phased move to full support for the Minimum SMETS1 Services (as per option 1 above) in cases where the minimum 37 is not already provided on day 1. The length of time for the phasing in of the full minimum 37 services would need to be determined. Where a SMETS1 DCC user interface option is chosen that implements a DUIS-like interface (SMETS1 DCC user interface options 1 and 2), the SMETS1 communication services would be provided in a way that mirrors the equivalent SMETS2 communication services set out in the DUIS, so would include all Service Reference Variants that can be IEPFR Consultation DCC Public Page 32 of 144

33 supported by SMETS1 meters (e.g. DCC would support Service Reference Variant 'Update Import Tariff (Primary Element)' in respect of SMETS1 meters, but not Service Reference Variant 'Update Import Tariff (Secondary Element)' as SMETS1 does not define a twin element meter). Appendix D provides additional detail on Service Reference Variants that would be supportable for SMETS1 meters. Although not part of the SMETS1 specification, some meter cohorts currently provide the functionality to send last gasp alerts. Network users would therefore be able to receive 'last gasp' alerts for these DCC enrolled SMETS1 meters under all communication services options. The six options are considered in the next section and greater detail of the analysis undertaken by DCC is presented in Appendix D, which includes a summary of the number of SMSOs that offer each of the Minimum SMETS1 Communication Services. Separately DCC has also submitted to BEIS details of the Minimum SMETS1 Services supported by each SMSO, but did not consider it appropriate to publish this information in the draft report Identifying Least Feasible Options and Dependencies on Integration Path Options Sensitivity analysis on the whole life cost of DCC providing a SMETS1 Service indicates that the number of core communication services supported by DCC does not have a material impact on the costs of any new systems procured by DCC. This is because when building new systems, there is only a small variable cost element for which a number of communication services is an input parameter. Taking this into account and following further analysis, DCC considers that some of the above options are not feasible for inclusion in comparative analysis and should be discounted for the following reasons: DCC has discarded option 2 as this would not offer any material cost savings and would have a significant negative impact on energy consumers with SMETS1 meters currently operating in prepayment mode. The lowest common denominator among current SMSO services does not include prepayment related services so, were this option to be taken forward, prepayment functionality would cease to be supported as a core communication service upon enrolment and energy consumers with SMETS1 meters operating in prepayment mode would be unable to top up; DCC has discarded option 3 as it does not offer any material cost savings and it does potentially result in a negative impact for some energy consumers, as it does not offer the full range of prepayment services as a core communications service that currently exist for some meter cohorts. Additionally, this option would provide none of the functionality as a core communication service that electricity distribution network operators and gas transporters would be eligible to use; and DCC has discarded option 4 as this does not present any material cost or time saving when compared to option 5, and would potentially result in a minor negative impact on energy consumers due to the withdrawal of some of the services that SMSOs currently support as a core communications service. DCC considers that communication services options that consider the provision of less than the Minimum 37 services are only relevant where integration path 5 is chosen (integrate to SMSO). This is because under integration path 4 (integrate to meter) there is no material time or cost benefit that derives from starting out with less than the minimum IEPFR Consultation DCC Public Page 33 of 144

34 37 services. As stated above, there is only a small variable element to the build cost for which the number of communication services is an input parameter. Should integration path 5 be chosen, current support for the Minimum SMETS1 Services varies amongst SMSOs and therefore the implementation of communication services options 1 or 6 would entail developing services that have not, to date, been implemented by SMSOs. There is no dependency between the communication services options and SMETS1 DCC user interface options; any SMETS1 DCC user interface option can accommodate any communication services option Evaluation against Criteria Table 3 contains an evaluation of communication services against the remaining options considered feasible (Options 1, 5 and 6), against criteria defined in Appendix C. Criteria Communication Services Option 1 (minimum 37) Communication Services Option 5 (as-is) Communication Services Option 6 (asis moving to minimum 37) Enrolment Service Costs Higher than option 5 but lower than option 6. Lowest. Highest. Costs are estimated to range between 0m - 20m The costs of the communications services options are dependent upon the level of effort required to deliver the required number of communication services within the build. Should integration path option 5 ( integrate to SMSO ) be adopted, there would be a cost associated with enhancements to some SMSO services. Should integration path option 4 ( integrate to meter ) be adopted, this communication services option becomes the basis for the service offering. As set out previously, this option is only applicable where integration path 5 is adopted. As this option avoids enhancements to SMSO services, DCC estimates that there would be a saving against option 1. As set out previously, this option is only applicable where integration path 5 is adopted. This option would drive additional cost vs. options 1 and 5, due to the need to build and test the phased introduction of services over multiple releases. DCC estimates that there would be an additional cost against option 1, which reflects the additional testing and management effort required to deploy the SMSO enhancements already factored into option 1 over multiple user facing releases. Delivery Timescales Should integration path 5 be adopted, this option requires enhancements to some SMSO services, which would be delivered in parallel with DCC build. As this option avoids enhancements to SMSO services, the implementation of the communication services would have a shorter duration than for option 1, however Same as option 5. The phased introduction of the 37 Minimum SMETS1 Services requires enhancements post go-live and therefore extends the overall DCC project over multiple user facing IEPFR Consultation DCC Public Page 34 of 144

35 Criteria Communication Services Option 1 (minimum 37) Communication Services Option 5 (as-is) Communication Services Option 6 (asis moving to minimum 37) Should integration path 4 be adopted, this option requires meter translation templates for each of the services and meter cohorts, which would be developed in parallel with the build of the core application. In either case, DCC build of the core SMETS1 data service is the major component of the build and test phase and represents the critical path, therefore the choice of communication services option has no material impact on timing for delivery of a live SMETS1 Service. DCC build of the core SMETS1 data service is still the major component of the build and test phase and so represents the critical path. This option therefore has no material impact on timing through build and test or commercial activity. releases. Delivery Confidence This option has no material impact on commercial delivery confidence as the number and nature of the parties with whom DCC would need to negotiate contracts is not determined by the communication services option selected but is a result of the other options selected. Should integration path 5 be chosen, SMSOs would be required to deliver enhancements that, in some cases would result in significant change to their technical solutions. Commercial delivery confidence is as for option 1 i.e. no material impact on delivery confidence. As this option avoids enhancements to SMSO services, technical delivery confidence is higher than for option 1 in the scenario where integration path 5 is chosen. Commercial delivery confidence is as for option 1 i.e. no material impact on delivery confidence. As this option avoids initial enhancements to SMSO services, technical delivery confidence is the same as for option 5 in the scenario where integration path 5 is chosen. Should integration path 4 be chosen, the required meter translation templates would be developed by a newly procured DCC service provider. Based on current DCC knowledge technical delivery IEPFR Consultation DCC Public Page 35 of 144

36 Criteria Communication Services Option 1 (minimum 37) Communication Services Option 5 (as-is) Communication Services Option 6 (asis moving to minimum 37) confidence is currently higher for integration path 4. Functionality This option delivers the minimum 37 service requests as envisaged in the SEC and includes prepayment functionality for all enrolled SMETS1 meters. This option delivers the service requests that can currently be supported by each of the incumbent SMSOs for each meter cohort they operate and therefore there is no loss of current functionality. The functionality provided by this option is a combination of that for option 5 and option 1. Approximately 4% of the projected SMETS1 meter population is operated by SMSOs that do not offer prepayment functionality and therefore could not be used in prepayment mode under this option without further changes later to the SEC and systems. All options provide the flexibility for additional services currently supported by SMSOs for each cohort to be provided as elective communication services. All options have no material impact on the performance or resilience of the system. Impact on Users Users will have a consistent set of services for all DCC enrolled SMETS1 meters. This option may require supplier and network operator users to operate separate business processes specific to each type of DCC enrolled SMETS1 meter in its estate, where DCC provides a different set of SMETS1 Services for those meter types. Impact on users will be as for option 5 initially, with further changes to harmonise business processes as full support for the Minimum SMETS1 Services is introduced for all SMETS1 meters. Deployment of the full capability over multiple releases is likely to increase cost to users versus options 1 or 5, but DCC does not consider these costs to be material. Table 3 Communication Services Options Evaluation IEPFR Consultation DCC Public Page 36 of 144

37 3.4.5 Conclusions on Communication Services Options Options 1, 5 and 6 as outlined above provide feasible core communication services options. Options 1, 5 and 6 will be considered as part of the commercial and implementation analysis in sections 6 to 7 below. The analysis and options for the core communication services are independent of the SMETS1 DCC user interface options. If an integration path option that uses existing SMSOs is chosen along with communication services option 1, enhancements will be required to some SMSO systems to achieve full coverage of the Minimum SMETS1 Services. If Communication Services option 6 is chosen, these enhancements will be required over time but not for Day 1. If an integration path option that replaces SMSOs is chosen, DCC considers that communication services option 5, which is predicated on SMSOs' existing service offerings, becomes invalid. The cost of enhancements to SMSOs' services to deliver the Minimum SMETS1 Services would not be a consideration and the additional cost associated with DCC delivering all 37 Services for all DCC enrolled SMETS1 meters using this integration path would not be material to the overall cost of enrolment Communications Services Common to all options DCC has further considered whether there are other services that are required in all communication service options; these are services necessary to support the lifecycle of SMETS1 meters enrolled in the DCC SMETS1 Service. If considered necessary, this would result in the inclusion of these services as part of the core offering (even though they are not currently listed in the Minimum SMETS1 Communication Services) and these would be required in combination with any communication services option selected. DCC has also considered whether there are other services that are listed in the Minimum SMETS1 communication services that would not actually be required. The communication services that have been considered are: Security related services; Non-Device Requests; Firmware Updates Scheduling; Commissioning; and Decommissioning. Security Related Services The Minimum SMETS1 Services include two services (see Table 4) relating to the update of security credentials held on meters. SMETS1 requires gas and electricity smart metering systems to be capable of updating or revoking security credentials held within them; however the nature of those security credentials is not specified in SMETS1 and varies across meter types. SMETS1 meters and the HESs that currently communicate with them do not hold security credentials consistent with those implemented for SMETS2 IEPFR Consultation DCC Public Page 37 of 144

38 and provided by SMKI. SMSOs do not place suppliers' security credentials on meters, nor do the suppliers hold the meters' security credentials (except in the case of a supplier acting as its own SMSO). The security section of this report sets out potential security controls for a DCC SMETS1 Service. It is not proposed that suppliers would be responsible for managing the security credentials held on DCC enrolled SMETS1 meters DCC (and service providers) would update security credentials on the meters according in accordance with a documented key management policy. The two services listed in Table 4 would therefore not be necessary for suppliers to operate enrolled SMETS1 meters and DCC considers that these should not form part of the SMETS1 Services. Service Request Variant Service Request Name Eligible Users 6.15 Update Security Credentials Import Supplier (IS) Gas Supplier (GS) 6.23 Update Security Credentials (CoS) Import Supplier (IS) Gas Supplier (GS) Electricity Distributor (ED) Gas Transporter (GT) Table 4 Minimum SMETS1 Services Relating to Security Credentials Non-Device Requests DCC considers that the Non-Device Requests listed in Table 5 are necessary for the effective administration and management of enrolled SMETS1 meters, regardless of the communication services option selected. Service Reference Description 8.2 Read Inventory (Current and Future Suppliers may use this service request) 8.4 Update Inventory Firmware updates Table 5 Non-Device Requests for the SMETS1 Services SMETS1 requires that gas and electricity smart metering systems be capable of executing a command to update firmware. An Update Firmware Service is included in the Minimum SMETS1 Services ('11.1 Update Firmware') and in the services currently provided by all SMSOs. SMETS2 and GBCS take a different approach to firmware updates, in that it requires gas and electricity smart metering equipment to be capable of executing separate commands to Receive Firmware and to Activate Firmware. As a result of this, the SMETS2 DCC User Interface Service '11.1 Update Firmware' is a Non-Device Request, which triggers distribution of Firmware images to the relevant communications hub without an IEPFR Consultation DCC Public Page 38 of 144

39 accompanying command to the target device to install the firmware. The '11.3 Activate Firmware' Service is then used to trigger the target device to install the firmware image on the required activation date. There are therefore two possible approaches to implementing the Update Firmware Service for enrolled SMETS1 meters, the choice of which is not material to the cost of enrolment: define an Update Firmware Service that is specific to SMETS1 meters and includes an activation date, triggering a command to the SMETS1 meter to receive, install and activate the Firmware Image supplied as part of the service request; or mimic the two stage process used for SMETS2 meters in order to preserve consistency of user experience. Firmware Images supplied as part of an Update Firmware Service Request targeted at SMETS1 meters would be held by DCC pending receipt of a corresponding Activate Firmware Service Request. DCC would then send a command to the SMETS1 meter to receive, install and activate the Firmware Image. Scheduling Whilst not included in the Minimum SMETS1 Services and not essential for the management of DCC enrolled SMETS1 meters, the ability to schedule certain service requests is a feature of the SMETS2 services that could be applied to the DCC SMETS1 Service to enhance the user experience (regardless of the SMETS1 DCC user interface option selected). There are three SMETS2 DUIS Service Requests, listed in Table 6, that are equivalent to Minimum SMETS1 Services and that users may request as DCC Scheduled Services. The advantage of using this method of scheduling is that WAN traffic can be managed by specifying scheduled messaging windows outside of peak times and it is consistent for users between SMETS1 and SMETS2. Service Reference Description 4.8 Read Profile Data 4.10 Read Network Data 4.16 Read Active Power Import Table 6 Minimum SMETS1 Services eligible to be DCC Scheduled in DUIS DUIS defines three Non-Device Requests for scheduling, which are listed in Table 7. DCC considers that this scheduling service could be offered as part of the SMETS1 Services without materially increasing cost, as the functionality would be built as part of the core DCC solution without requiring meter or SMSO specific translation. Service Reference Description 5.1 Create Schedule IEPFR Consultation DCC Public Page 39 of 144

40 Service Reference Description 5.2 Read Schedule 5.3 Delete Schedule Table 7 DUIS Service Requests for Scheduling Commissioning Eligible Meters first in DCC In section N4.4 of the SEC, it states that DCC shall include within the IEPFR: i. Options for provision by DCC to Users of a service for Eligible Meters to be commissioned first in the DCC (in addition to Enrolment post-commissioning); All of the SMETS1 devices known to DCC require a similar set of commands to bring them in to service (e.g. join meter to ZigBee HAN), which can be aligned to equivalent SMETS2 DCC User Interface Services, albeit that the manufacturers have implemented them in various ways. SMSOs and HES vendors have implemented different combinations of these commands as "commissioning" business processes and offer different interfaces to their users to trigger the process. In order to harmonise these different approaches, DCC considers that it should align the process for commissioning SMETS1 meters as far as possible with that established for SMETS2, using a common set of services accessed via the user interface. As set out in the section 3, in the case of integration path option 5 ( integrate to SMSO ) which uses SMSO services, it will be necessary to make changes to any HES that currently bundles together the relevant meter commands with other types of command. This is so that that the meter commands executed by the HES in order to commission a SMETS1 meter mapped to the equivalent service request submitted by the user. DCC's analysis of the current commissioning services provided by SMSOs in relation to SMETS1 meters and the differences between those services and the existing SMETS2 DCC User Interface Services is contained in Appendix D. Decommissioning Enrolled SMETS1 Meters DCC's analysis of the current decommissioning services provided by SMSOs in relation to SMETS1 meters and the differences between those services and the existing DCC User Interface Services is contained in Appendix D. DCC considers that the service requests that enable the decommissioning of DCC enrolled SMETS1 meters should be provided as a non-device services that are common to all SMETS1 meters and are in a format that is the same as that for the existing equivalent DCC User Interface Services Provision of SIM cards by DCC to support new communications hubs Provision of a service for commissioning Eligible Meters first into DCC, as required by SEC section N4.4(i), implies a need to commission the associated communications hubs. If suppliers procure additional stock of communications hubs from their existing vendors during the life of the DCC SMETS1 Service, there may be a need for DCC to take a role in IEPFR Consultation DCC Public Page 40 of 144

41 ordering and providing SIM cards for suppliers to install in those communications hubs. This is because once the SMETS1 meters are enrolled, DCC would have the contractual relationship for SMETS1 communication services, which will provide the means by which SIM cards would be ordered. Arrangements for installation of SIM cards into communications hubs and provision of the communications hub hardware would continue to be the responsibility of suppliers, as is currently the case for SMETS1 meters. The numbers of SIM cards likely to be required by suppliers under this service are limited by the following factors: SIMs would only be required for communications hubs used as part of maintenance of SMETS1 smart metering systems already deployed, since enrolment will take place after the SMETS1 End Date. Data relating to failure rates of specific SMETS1 devices are commercially sensitive; however for modelling purposes, DCC has assumed an overall dilapidation rate of 1% per annum; not all communications hubs are capable of being replaced in the field independently of the electricity meter with which they form a Smart Metering System. After the SMETS1 End Date, suppliers will not be permitted to replace a these SMETS1 Smart Metering Systems on a like-for-like basis; and a number of suppliers have indicated that, if they were required to visit a consumer's premises to investigate a faulty SMETS1 device, they would not replace individual components of the Smart Metering System but would replace the entire Smart Metering System with one that complies with the version of SMETS extant at that time. This is particularly true where the meter was gained through churn and is not of a type originally installed by that supplier, or where the meter is nearing the end of its commercial or technical lifespan. DCC therefore considers that the impact on DCC of providing this service, if required, would be low. Because of the limited number of SIMs likely to be required, administration of the ordering process would not require special tooling and could be provided within the range of estimated costs for the SMETS1 Service Consultation Questions Consultation Questions: Communications Service 9 Do you agree that the additional services that are currently provided by SMSOs that are not part of the core offering should be made available by DCC as elective communication services, should the supplier wish to continue to receive those services? Please provide a rationale for your views 10 Do you agree that communication services options 2, 3 and 4 should be discounted? Please provide a rationale for your views. 11 Do you agree with the evaluation of communication services options 1, 5 and 6 and do you consider that there are other advantages and disadvantages of any of those options that should be considered? Please provide a rationale for your IEPFR Consultation DCC Public Page 41 of 144

42 Consultation Questions: Communications Service views. 12 Which communication services option do you consider is preferable? Please provide a rationale for your views. 13 Do you agree that the two security-related service requests set out in Table 4 are not required for DCC enrolled SMETS1 meters? Please provide a rationale for your views. 14 Do you agree that the Non-Device requests listed in Table 5 are required for DCC enrolled SMETS1 meters? Please provide a rationale for your views. 15 Do you have a preference for the approach to implementing the Update Firmware Service for enrolled SMETS1 meters? Please provide a rationale for your views. 16 Would you use DCC scheduled services if offered by DCC in respect of enrolled SMETS1 meters? Please provide a rationale for your views. 17 Do you agree that DCC should provide a standardised set of service requests for commission and decommissioning SMETS1 devices that most closely approximates the process for SMETS2 devices? Please provide a rationale for your views. 18 Do you anticipate ordering additional communications hubs from your existing vendor(s) during the life of the DCC SMETS1 Service and, if so, would you require DCC to provide SIM cards? Please provide a rationale for your views. 3.5 Prepayment Options Context There is currently only a minority of SMSOs whose services support SMETS1 meters functioning in prepayment mode. The Minimum SMETS1 Services include service requests necessary to change payment mode, configure meters, send top ups, manage debt etc. When a consumer wishes to top up a SMETS1 prepayment meter, the meter requires a valid Unique Transaction Reference Number (UTRN) as part of an Add Credit Command received either via the meter's WAN Interface (i.e. an Over the Air (OTA) top up) or the user interface (i.e. a manual top-up). There are similar requirements for SMETS2 meters operating in prepayment mode. A UTRN must also be provided to the consumer at the point of sale to enable the consumer to top up manually as a fall-back should the OTA top up fail. The key difference between SMETS1 and SMETS2 meters in respect of UTRNs is that there is a standardised algorithm specified in GBCS to generate a UTRN for a SMETS2 IEPFR Consultation DCC Public Page 42 of 144

43 meter, using SMKI security credentials that will be known to the supplier; whereas the algorithm to generate a UTRN for a SMETS1 meter is specified by each meter manufacturer and the relevant security credentials may be known only to the SMSO, or to both the SMSO and the supplier. The suppliers and service providers currently active in the SMETS1 prepayment market have taken different approaches as can be seen in Figure 10 below. Top Up UTRN SMSO UTRN PAN & Top Up Command Payment Service Provider UTRN PAN & UTRN PAN & Top Up Command Consumer PAN & PAN & UTRN Energy Suppliers Colour coding of arrows corresponds to the party providing the data specified in the arrow s caption Figure 10 Existing Varied Approaches to prepayment for SMETS1 In the current SMETS1 market, UTRN algorithms are specific to each meter manufacturer so it would be complex and costly for each supplier to develop the capability to generate UTRNs in numerous different ways. The current prepayment arrangements for SMETS1 meters do not guarantee continued prepayment operation when meters churn from one supplier party to another if the SMETS1 meter is of a type not deployed by that supplier party. There are also meters cohorts that are not currently operated in prepayment mode and for which no such arrangements are expected to be in place at the time that a DCC SMETS1 Service would go live. Whether or not prepayment services would be offered by DCC in relation to such meters were they to be enrolled with DCC depends upon the communications service option that is selected, as discussed in the previous section. It is worth noting however, that if communication services options 5 or 6 were selected, which start with the as-is functionality and do not offer prepayment-related service requests in relation to all meter cohorts on day 1, that this would not adversely impact existing energy consumers with prepayment meters as they would continue to get the service provision that currently exists. IEPFR Consultation DCC Public Page 43 of 144

44 The differences between the various retail models for consumers with SMETS1 prepayment meters and the model for SMETS2 prepayment meters are explored in Appendix E Requirement Whilst not an explicit requirement of section N of the SEC, DCC considers that industry requires a consistent and interoperable solution for prepayment to enable a supplier (or its nominated agent) to obtain a valid UTRN for any DCC enrolled SMETS1 meter for which it is the registered supplier. A model whereby suppliers continue to use the existing prepayment solutions provided by SMSOs for DCC enrolled SMETS1 meters presents the following issues: under integration path option 4 ( integrate to meter ), SMSOs would cease to have access to the security keys required to operate a prepayment service, as meters would be migrated out of SMSOs' HES and, if the security model outlined in section 4 is implemented, security key management would become a DCC responsibility. Although Suppliers could have access to prepayment keys held by DCC and pass those keys to an SMSO that they contract with separately, the commercial viability for SMSOs to provide standalone UTRN services is questionable. Use of SMSOs to provide UTRNs would also require the registered supplier for DCC enrolled SMETS1 meter to contract with the SMSO that generates UTRNs for that meter, requiring the supplier to have in place multiple contractual relationships for UTRN provision in relation to multiple meter cohorts (rather than a single contract governing the service provision, being the SEC); and under integration path option 5 ( integrate to SMSO ) continuing to use existing SMSO arrangements would require the registered supplier for DCC enrolled SMETS1 meter to also contract with the SMSO that generates UTRNs for that meter, so as with integration path 4 the supplier would have to establish multiple contractual relationships for UTRN provision in relation to multiple meter cohorts (rather than a single contract governing the service provision, being the SEC). In developing a DCC UTRN generation service, the following challenges arise: in the case of integration path option 4 ( integrate to meter ) which obviates the need for SMSOs, DCC does not have the option to source the existing UTRN generation function from the incumbent SMSO where one exists; and a supplier that currently has the ability to generate UTRNs for SMETS1 meters that it installed requires access to security credentials held on those meters, which it would no longer control once meters are DCC enrolled, due to the security control proposed in section 4, in which suppliers do not manage meter security credentials Options Summary Based on the analysis of existing retail models, DCC considered the following factors in order to identify options for a DCC UTRN generation solution for a DCC enrolled SMETS1 meter operating in prepayment mode, using the prepayment related services included in the Minimum SMETS1 Communication Services: Which party or parties should generate UTRNs in their systems (DCC or the supplier)? IEPFR Consultation DCC Public Page 44 of 144

45 Which party or parties would be entitled to request services from DCC in the prepayment top-up transaction (the supplier and/or the Payment Services Provider (PSP))? DCC has identified three technical options for provision of a function or service for the generation of UTRNs that industry systems can interface to: 1. DCC provides a service to generate UTRNs which is available to both the energy supplier and the PSP (e.g. PayPoint, Payzone, and Post Office). The generated UTRN will be passed back to the requestor and, where not the requestor, also to the supplier; 2. DCC provides a service to generate UTRNs but this is only available to the energy supplier, and the PSP interfaces via the energy supplier; and 3. DCC provides a standardised UTRN generation function for energy suppliers to integrate into their systems to enable them to generate UTRNs themselves and the energy supplier interfaces with the PSP. DCC would need to provide a mechanism for suppliers to access the necessary security credentials (prepayment key), which would remain under DCC management UTRN Generation Options Option 1 - DCC generates UTRNs which can be requested by the Supplier and the PSP For this option, DCC systems would create a UTRN based on the consumer s Payment Allocation Number (PAN) and the amount to credit the meter. DCC would receive the information required to generate the UTRN as a direct request from the PSP or supplier party and generate the UTRN, passing this back to the requestor, who then shares this with the supplier party (if not the requestor) and consumer. Figure 11, below, shows how DCC prepayment service could interface with the PSP or the supplier. IEPFR Consultation DCC Public Page 45 of 144

46 Consumer f. Top Up Service Request e. UTRN a. PAN & Payment Service Provider b. PAN & d. UTRN e. UTRN b. PAN & d. UTRN b. PAN & Supplier UTRN Generator d. UTRN f. Top Up Service Request Colour coding of arrows corresponds to the party providing the data specified in the arrow s caption Figure 11 UTRN Generation Option 1 In Figure 11: the consumer will provide the PSP with their PAN and the amount to credit their meter; the PSP will send this information to DCC (or the supplier may also perform this step on behalf of the PSP); DCC will calculate the UTRN for the amount of credit and the meter identified by the PAN. The algorithm used to calculate the UTRN will be specific to the meter type identified by the PAN; DCC will return the UTRN to the requestor; the PSP will pass the UTRN to the point of sale for issue to the consumer and it will pass the UTRN to the supplier; and the supplier or PSP will add the credit to the meter using the Top Up Device service request, which it will send to DCC SMETS1 Service. Option 2 - DCC generates UTRNs which can be requested by the Supplier only, and PSP interfaces via the Supplier In this option, DCC prepayment service would receive the information required to generate the UTRN as a request from the supplier (which may originate from a PSP) and generate the UTRN. As with option 1, DCC systems would create a UTRN based on the consumer s PAN and the amount to credit the meter. The UTRN is then passed back to the supplier, who passes it back to the PSP and on to the consumer. IEPFR Consultation DCC Public Page 46 of 144

47 UTRN Generator Consumer e. UTRN a. PAN & Payment Service Provider b. PAN & d. UTRN d. UTRN c. PAN & Supplier Colour coding of arrows corresponds to the party providing the data specified in the arrow s caption f. Top Up Service Request Figure 12 UTRN Generation Option 2 In Figure 12, all interfacing between the PSP and the UTRN generator is being provided by the supplier: the consumer will provide the PSP with their PAN and the amount to credit their meter; the PSP sends the PAN and amount of credit to the supplier; the supplier sends the PAN and amount of credit to DCC. DCC calculates the UTRN for the amount of credit and the meter identified by the PAN. The algorithm used to calculate the UTRN will be specific to the meter type identified by the PAN; DCC will send the UTRN to the supplier. The supplier will pass the UTRN to the PSP; the PSP will pass the UTRN to the point of sale for issue to the consumer; and the supplier will add the credit to the meter using the Top Up Device service request, which it will send via the SMETS1 DCC user interface. Option 3 - DCC provides standardised UTRN generation function for Suppliers to integrate into their systems For this option, DCC would produce UTRN generation software that suppliers will each integrate into their systems. As before, this system would create a UTRN based on the consumer s PAN and the amount to credit the meter. In this option, DCC would provide no support at a transactional level. IEPFR Consultation DCC Public Page 47 of 144

48 The service could be implemented in one of two ways depending upon how the supplier chose to implement it. Either the PSP would interface directly with supplier s UTRN generation function, or would interface with it indirectly via the supplier. e. UTRN Payment Service Provider b. PAN & d. UTRN x a. PAN & Supplier UTRN Generator f. Top Up Service Request Consumer Colour coding of arrows corresponds to the party providing the data specified in the arrow s caption Figure 13 UTRN Generation Option 3 In Figure 13, DCC provides a UTRN generator that the user integrates with its internal systems. The user will interface with the PSP and use the UTRN generator to calculate UTRNs for the amount of credit and the meter identified by the PAN. the consumer will provide the PSP with their PAN and the amount to credit their meter; the PSP sends the PAN and amount of credit to the supplier; the supplier will calculate the UTRN for the amount of credit and the meter identified by the PAN using DCC UTRN generator software and the prepayment security key for the meter. The algorithm used to calculate the UTRN will be specific to the meter type identified by the PAN; the supplier will pass the UTRN to the PSP; the PSP will pass the UTRN to the point of sale for issue to the consumer; and the supplier will add the credit to the meter using the Top Up Device service request, which it will send via the DCC SMETS1 user interface Evaluation against Criteria Table 8 below contains an evaluation of the UTRN generation options against the criteria defined in Appendix C. Criteria UTRN Option 1 UTRN Option 2 UTRN Option 3 Enrolment Service Costs Similar to other UTRN generation options Similar to other UTRN generation options Costs are estimated be approximately 10m Similar to other UTRN generation options IEPFR Consultation DCC Public Page 48 of 144

49 Criteria UTRN Option 1 UTRN Option 2 UTRN Option 3 Delivery Timescales Current estimates show no material difference between UTRN generation options in terms of impact on enrolment service costs. Options 1 and 2 require very similar technical solutions and therefore similar development, hosting and support costs. The development timeline for options 1 and 2 is the same, as they both require the same technical solution. Should integration path option 5 ( integrate to SMSO ) be chosen, there is the potential to use existing SMSO UTRN generation (where such functionality exists). DCC would still need to develop the user interface for the service and a UTRN generation capability for meters for which there is no existing SMSO capability. As DCC will need to develop the core functionality for UTRN generation for those cohorts where no generation functionality currently exists, use of that functionality for all DCC enrolled SMETS1 meters would not materially increase the time to deliver the UTRN service. Should integration path 4 be chosen, DCC would develop the UTRN generation capability for all DCC enrolled SMETS1 meters, as the option to use existing SMSO UTRN generation functions would not exist. Option 3 requires a different technical solution with no DCC hosting requirement, but a higher degree of software support due to the need to support multiple users. This option requires the development of a similar UTRN generation capability to that required for options 1 and 2. This option does not require the implementation of a DCC hosted user interface, but instead requires support to users during deployment of the software. The overall time to deliver this option does not differ significantly from options1 and 2. DCC build of the SMETS1 data service set out in section 3.2 is the major component of the build and test phase and represents the critical path, therefore the choice of UTRN generation option has no material impact on timing for delivery of a live SMETS1 Service. Delivery Confidence Functionality These options have no material impact on delivery confidence for the SMETS1 Service. The service is capable of being developed and delivered separately from the other DCC services, or elements may be procured from existing SMETS1 service providers, so commercial delivery confidence is high. All solutions require that DCC has access to a UTRN generation algorithm or a capability that generates those algorithms, which appears to be feasible as this stage. Technical delivery confidence is high as the generation of UTRNs is low complexity relative to the other elements of the SMETS1 Service. In all UTRN generation options, for the purposes of analysis DCC has assumed that the prepayment related services included in the Minimum SMETS1 Services are provided so that OTA prepayment top ups can be sent to meters. All UTRN generation options enable consumers to obtain a UTRN for manually applying top ups to meters. These options have no material impact on the performance or resilience of DCC systems. Impact on Any party (supplier or PSP) that is eligible to use DCC UTRN generation service will need to integrate with the Users will need to integrate DCC IEPFR Consultation DCC Public Page 49 of 144

50 Criteria UTRN Option 1 UTRN Option 2 UTRN Option 3 Users interface for requesting UTRNs. If the DCC user interface is used (discussed in section below), suppliers will already have a connection in place, PSPs will not. If a new interface is implemented, all eligible parties will need to establish a new connection to that interface. prepayment service into their system. In many cases, the only interface that currently exists between a supplier and a PSP is for periodic payment reconciliation, which would not enable UTRNs to be passed between the supplier and PSP in near real time. Should a supplier require UTRNs from a PSP (e.g. to enable the supplier to submit a Top Up Device Service Request, as in option 1) or a PSP require a UTRN from a supplier (e.g. where the supplier obtains/ generates the UTRN, as in options 2 and 3), PSPs and suppliers would need to put the necessary interfaces in place to support this. Impact on consumers Under any of these options, consumers will be able to top up and receive a UTRN as a fall back. The performance of the UTRN generation service will be specified such that UTRNs will be provided in near real-time, as they are today. There may be an increase to the overall time for OTA top ups as a result of a twostep top up process (see discussion in section below). The increase would be negligible and would be unlikely to be noticeable to consumers when checking that the top up has been applied. Table 8 Prepayment Options Evaluation Further Considerations relating to Prepayment Service Requests Top-Up Device Requests For DCC enrolled SMETS2 meters, a Top Up Device request must contain a valid UTRN in order for an OTA top up to be sent to a meter. However the majority of SMETS1 prepayment solutions use a single top up device request to the SMSO to trigger both the generation of a UTRN and an OTA top up containing that UTRN. There are therefore two possible methods that may be adopted for DCC enrolled SMETS1 meters: mirror the SMETS2 process. In this case, the process for DCC enrolled SMETS1 meters would have two steps: a UTRN is obtained, using a valid PAN and top up value, and a Top Up Device request containing that UTRN is submitted via the SMETS1 DCC user interface, resulting in an OTA top up being sent; or continue the single step process used by most SMETS1 prepayment solutions whereby a Top-Up Device request containing a valid PAN and top up value is submitted via the DCC SMETS1 user interface, resulting in a UTRN being generated and returned to the requestor and an OTA top up being sent. The process for topping up DCC enrolled SMETS1 meters could also be more closely aligned to current industry processes by allowing the supplier's nominated Payment Services Provider ( PSP ) to send a Top-Up Device service request to submit UTRNs IEPFR Consultation DCC Public Page 50 of 144

51 obtained from DCC. The current DCC SMETS2 Top-Up Device Service Request is only available to suppliers, however in the current SMETS1 process, it is common for the PSP to submit the top-up request directly to the SMSO, without passing through the supplier. There is therefore also an option to make the DCC SMETS1 Top-Up Device service request available to PSPs, for either a one step or a two-step top up process. Provision of the interface for requesting UTRNs Under prepayment options 1 and 2, there is a requirement for DCC to provide an interface for the UTRN generation service. There is no existing equivalent SMETS2 interface for UTRN generation, however it is possible that the SMETS1 DCC user interface (options for which are described in section 3.3) could also be used for the UTRN generation service. The SMETS1 DCC user interface will be used to provide the SMETS1 communication services, including the Top-Up Device service request for OTA top ups and, regardless of the user interface option selected, DCC will implement the appropriate security controls for an interface that can be used to send supply affecting commands. DCC therefore considers that the SMETS1 DCC user interface should be used for all OTA top ups, whether as part of a single step process that also results in the generation of a UTRN, or as the second step in a two-step process, where the UTRN is obtained in the preceding step. Providing the Top-Up Device service request via a different interface (were the UTRN interface to be different to the SMETS1 DCC user interface) would mean that all of the security controls applying to the SMETS1 user interface would need to be replicated for the interface used to send Top-Up Device service requests. The UTRN generation service on its own is not capable of sending supply affecting commands and therefore has different security requirements to the SMETS1 DCC user interface. It also may have different availability and performance requirements compared to the SMETS1 DCC user interface. Consumers must be able to top up prepayment meters at any time, therefore the processing of requests for UTRNs must take place in near real-time to enable the UTRN to be provided to the consumer at the point of sale for manual input should the OTA top up not reach the meter in a timely manner. This requires a very highly available interface for the UTRN generation service that, if it shares the SMETS1 DCC user interface, would require enhancements to the architecture for the SMETS1 DCC user interface. So whilst a one step process for UTRN generation and OTA top-ups may have its attractions, given that this would need to be executed via the SMETS1 DCC user interface, it would need to be subject to a cost benefit analysis. The relative advantages and disadvantages of a one and two step prepayment top up process are set up in table 9. Two step process Single step process Advantages Disadvantages Advantages Disadvantages Maintains consistency of supplier experience across DCC enrolled SMETS1 and SMETS2 meters. Enables the UTRN generation service to be separated from the processing of service Requires suppliers and PSPs to change from their current processes. Minimises change for suppliers and/or PSPs as they can continue to operate current processes for SMETS1 meters (albeit with a DCC provided service in place of that currently Adds complexity for suppliers with separate prepayment top up processes for SMETS1 and SMETS2 meters. The interface will need to meet the performance and availability requirements necessary IEPFR Consultation DCC Public Page 51 of 144

52 Two step process requests (Communication Services) so that higher availability and performance standards for the UTRN interface do not need to be applied to the SMETS1 DCC user interface which is used for processing service requests. provided by SMSOs). Single step process to support UTRN generation transactions. This might be considered excessive as the other service requests that can be sent across the SMETS1 DCC user interface do not require such high performance and availability requirements Table 9 Relative Advantages and Disadvantages of a one and two step top up process IHDs that function as a Pre-Payment Interface Device DCC is also aware that a number of suppliers have deployed In Home Displays (IHDs) that function as a prepayment interface device (similar to the SMETS2 PPMID) such that consumers can manually input UTRNs via the IHD. As not all SMETS1 IHDs have this functionality (it is not a requirement of SMETS1), DCC considers that any such IHD should be identified as a separate device type in the Smart Metering Inventory so that, on churn, a gaining supplier will have visibility of its enhanced functionality. This would allow suppliers to advise consumers correctly Conclusions Technically, UTRN generation options 1, 2 and 3 outlined above are feasible solutions to support the operation of DCC enrolled SMETS1 meters operating in prepayment mode. There are interdependencies between the UTRN generation options and the integration path options and communication services options: UTRN generation option 3 requires that DCC has access to the UTRN algorithm for each Eligible Meter type in order to build a solution that can be released to suppliers; UTRNs. For options 1 and 2, incumbent SMSOs that currently generate UTRNs could continue to be used by DCC to generate UTRNs for meter cohorts that are supported via an integration path that retains the SMSO; Options 1 and 2 requires that DCC has access to the UTRN algorithm where DCC is not using existing SMSO capability to generate UTRNs; and The scope of the DCC prepayment solution (under any prepayment option) would be limited should communication services option 5 or 6 be selected, as for meter cohorts that cannot currently be operated in prepayment mode, no DCC prepayment solution would be made available. The interface between the PSP and the DCC prepayment service does not exist and so would need to be developed under option 1. IEPFR Consultation DCC Public Page 52 of 144

53 3.5.8 Consultation Questions Consultation Questions: Prepayment 19 Do you agree with the options that DCC has identified for the provision of a UTRN generation service and are there others that should be considered? Please provide a rationale for your views. 20 Do you agree with the assessment of the advantages and disadvantages of each UTRN generation option and are there others that should be considered? Please provide a rationale for your views. 21 Which UTRN generation option do you consider to be preferable? Please provide a rationale for your views. 22 Do you consider that payment service providers should become eligible to use the Top- Up Device services on a supplier s behalf? Please provide a rationale for your views. 23 Do you consider that a one-step or two-step process for sending an OTA Top up to a SMETS1 Meter is preferable? It would be useful to understand the advantages and disadvantages of each approach as you perceive them, including the relative efficiencies to a user of a single step process (which aligns with current SMETS1 processes and implies a single interface) versus a two-step process (which more closely aligns with SMETS2 processes and results in two interfaces)?please provide a rationale for your views. 24 Do you agree that SMETS1 IHDs with PPMID-like functionality should be included in the Smart Metering Inventory as a separate device type to other IHDs? Please provide a rationale for your views. IEPFR Consultation DCC Public Page 53 of 144

54 4 Security 4.1 Introduction This section of the draft report summarises DCC s security analysis. It discusses possible security measures for a DCC SMETS1 Service. It describes the security issues associated with the various technical options and the impact on the delivery cost and timescales of implementing various security controls. DCC has consulted security experts from within Government and industry in developing the security controls and options presented in this report. The sensitivity of the security risks in Smart Metering Systems means that this section has been purposefully written at a high level and does not discuss specific risks. In accordance with the requirements in section N of the SEC, the SEC Panel, via the Security Sub Committee (SSC), has been engaged in ensuring that sensitive security information is not included in the published report. A security report, which discusses specific security risks, has been provided to BEIS. Additionally, that separate report will be provided to the SSC during the consultation period for this draft report Context DCC performed the security analysis in accordance with section N2.10 of the SEC, which states that DCC shall: prepare a risk assessment detailing the security risks associated with operating and using the SMETS1 Services; detail the measures (including Systems) proposed in order to ensure that the level of security risk to the DCC Total System, Enrolled Smart Metering Systems and/or User Systems will not be materially increased as a consequence of the provision of the SMETS1 Services; and prepare a risk treatment plan outlining the residual risks which exist once the measures referred to above have been taken. The key message from the SEC extract above is that this report should detail the measures proposed to ensure there is no material increase in risk to the DCC Total System, Enrolled Smart Metering Systems and User Systems. The risk assessment and the risk treatment plan have not been included in this report, for the reasons outlined above. BEIS has been consulted to ensure the methodology employed is consistent with that undertaken for the enduring SMETS2 solution. The DCC Total System is defined in the SEC and, prior to SMETS1 enrolment, this includes: the systems of the SMETS2 service providers; and the communications hubs of SMETS2 Home Area Networks (HANs). Post SMETS1 enrolment, the DCC Total System would also include the systems used by SMETS1 service providers, namely: IEPFR Consultation DCC Public Page 54 of 144

55 incumbent SMSO systems (should integration path 5 be chosen); the SMETS1 CSP systems; and any new SMETS1 data systems. Enrolled Smart Metering Systems refers to the SMETS1 Smart Metering Systems enrolled with DCC, and User Systems are the systems of DCC users Material Increase in Risk The definition of what constitutes a material increase in risk is to some extent subjective. DCC has taken the view that there is a material increase in risk where the residual risk is greater than the equivalent risk in the SMETS2 end-to-end systems. The residual risks associated with the SMETS2 systems are identified in the SMETS2 risk treatment plan (RTP). DCC has developed an interpretation of these risks, in discussion with BEIS, and has used this information to calibrate the assessment of the SMETS1 risk. This has enabled DCC to form a view on the residual risk associated with operating the SMETS1 Service. Given the differences between SMETS2 and SMETS1 devices and the systems used to communicate with them, the objective of the security analysis is to determine whether: there would be a material increase in risk to the DCC Total System, Enrolled Smart Metering Systems or User Systems if no additional security controls were to be applied; and whether measures could be implemented that would result in SMETS1 meters being enrolled without materially increasing the residual risk Security Measures This section describes the security measures that would be expected in the systems used to manage the SMETS1 meters that would be enrolled with DCC. The controls are described in the context of an option-neutral high-level architecture as set out in Figure 14. The SMETS1 Integration element consists of those parts of the SMETS1 data systems that provide the user interface functionality and the functionality required to communicate with the HES, such as request management. The HES and the SMETS1 Integration together comprise the SMETS1 data systems. The implementation of the components shown in Figure 14 will depend on the technical options chosen (as set out in section 3). For example, the responsibility for operating the HES element of the SMETS1 data system will depend on the selected integration path option, and the scope of the SMETS1 Integration element will depend on both the integration path and the SMETS1 DCC user interface options. IEPFR Consultation DCC Public Page 55 of 144

56 4.1.4 DCC Users Figure 14 Option Neutral High Level Architecture for an End-to-End SMETS1 System A DCC user would have to comply with the security requirements in SEC section G (where applicable) and, as is the case with DCC enrolled SMETS2 meters, their systems would need to be subjected to an independent security assessment. DCC users would need a secure mutually-authenticated connection with strong cryptographic controls to communicate with the SMETS1 integration system. In addition DCC users would need to use public key infrastructure (PKI) so that the HES can ensure the authenticity and integrity of the content of the messages sent via the SMETS1 integration systems SMETS1 Integration Systems DCC service providers would need to comply with the security requirements in SEC section G and again systems would to be subjected to an independent security assessment. The integration system would need to provide secure mutually-authenticated connections with strong cryptographic controls to DCC users (as referenced in section 4.1.4) and to the HES. In accordance with the current security arrangements in the SEC, the integration systems would need to apply a number of controls to service requests received from DCC users. This includes authentication and access controls, message content validation, anomaly detection and prevention, and security monitoring Head End Systems The HES would need to comply with the applicable security requirements in SEC section G, and systems would be subject to an independent security assessment. The HES would need to have a secure mutually-authenticated connection into the SMETS1 integration system with strong cryptographic controls (as referenced in section 4.1.5). Strong cryptographic methods, such as PKI, would need to be used to ensure the authenticity and integrity of messages sent to and originating from a DCC user. Secure mutually-authenticated connections with strong cryptographic controls would need to exist between the HES and the SMETS1 HAN. Energy consumption data will need to be processed by the HES and, where necessary, the confidentiality of this data will need to be protected, both during processing and when stored by the HES. Having a short retention time for meter responses at the HES and ensuring that no energy consumption data is stored after it has been processed, along with other controls including role based access controls and clearance for users, would protect the confidentiality of consumption data. Due to the differences between the SMETS1 and SMETS2 specifications, and the potential for security risk aggregation following enrolment and adoption, further additional IEPFR Consultation DCC Public Page 56 of 144

57 architectural security options have been developed to support risk mitigation at the HES. The security options were developed by taking into account the security requirements of the SMETS2 system and the increase in aggregated risk due to incorporating DCC enrolled SMETS1 meters in a single integrated DCC SMETS1 system. There are three potential security options that could provide further mitigation of the residual risks at the HES. The options are: system hardening - Security measures at the HES would be strengthened to reduce the probability of compromise; islanding - Islanding involves creating a greater number of HESs, each of which would be limited in the number of meters with which it can communicate. Limiting the number of meters connected to each island would lower the impact of a compromise of a single island; and enhanced key management - This option would involve the creation of a separate organisation to support aspects of the management and use of cryptographic keys for communicating messages with meters SMETS1 CSPs The SMETS1 CSPs would need to comply with the applicable security requirements in SEC section G. The SMETS1 CSPs would also need to ensure that the networks they provide have appropriate network access controls to ensure communications are only possible between a HES and its communications hubs. A further security option to reduce the aggregated risk is to implement SMETS1 CSP limitations. Network controls would be applied at the SMETS1 CSPs to limit the number of simultaneous connections between a HES and its meters, reducing the impact of compromise SMETS1 HAN The SMETS1 HAN would need to prevent unauthorised devices connecting to the HAN and would need to be capable of secure communications with the HES (as referenced in section 4.1.6), including secure mutually-authenticated connections with strong cryptographic to protect the confidentiality of sensitive data. SMETS1 metering devices might need to undergo independent assurance, as might future firmware versions. 4.2 Analysis of Security Aspects of Technical Options In this section the impact on security of each of the technical options in section 3 is considered, specifically: Integration path options; User interface options; Communication services options; Prepayment options; and Implementation options. IEPFR Consultation DCC Public Page 57 of 144

58 The extent to which these options would impact the viability, cost or security risk is discussed in the sections below Integration Path This aspect of the technical solution relates to the systems that DCC uses to communicate with SMETS1 meters. Two integration paths are identified as being the most the most feasible: integration path 4: Create a new SMETS1 data services capability to directly integrate to existing SMETS1 CSPs and existing meters (integrate to meter); and integration path 5: Use existing SMETS1 data services capability (SMSO) which integrates to existing SMETS1 CSPs and existing meters (integrate to SMSO). All of the additional security controls and options identified in section are technically viable for a HES, regardless of the choice of integration path. Provided the recommended controls and options are applied, there would be no difference in the residual risk between the integration paths. With integration path 4, it will be necessary to ensure that the HESs operated by the new SMETS1 data services provider implement the controls outlined in section With integration path 5, it will be necessary to ensure that the existing HESs implement the controls outlined in section This may involve applying system hardening to multiple HESs which could result in additional SMSO costs, depending on the existing systems. The enhanced key management option could also result in increased SMSO costs and implementation timescales under integration path 5, as compared to integration path 4, due to the need to integrate this functionality with multiple legacy HESs SMETS1 DCC user interface This aspect of the technical solution relates to the implementation of the interface between DCC users and the integration systems. There are three user interface options that are identified as being feasible: SMETS1 DCC user interface Option 1: Message format based on SMETS2 DUIS utilising the existing interface hosted by the SMETS2 DSP; and SMETS1 DCC user interface Options 2 and 3: interface provision competitively procured with message format either based on SMETS2 (as amended) or a new SMETS1 format. Regardless of the SMETS1 DCC user interface option chosen, it will be necessary to ensure that the security measures outlined in section and section are applied. The security measures needed at the interface are technically viable for all SMETS1 DCC user interface options. There are therefore no security implications that prevent any of the individual user interface options. However the security requirements will influence the implementation costs and timescales. With SMETS1 DCC user interface option 1, the existing SMETS2 DSP measures for authentication and access controls, message content validation, anomaly detection and prevention, and security monitoring could be re-used (either wholly or in part) which would reduce the implementation costs for these controls. IEPFR Consultation DCC Public Page 58 of 144

59 With SMETS1 DCC user interface options 2 and 3, equivalent controls would need to be re-procured and implemented. It would be expected that building these measures into a newly hosted interface would have a higher cost than connecting to an existing DCC user interface. The implications of the security requirements for these options on cost, timescales, delivery confidence, and impact on functionality and users, have been taken into account in the overall option analysis and are reported on separately in this IEPFR Communication Services This aspect of the technical solution relates to the scope of the communication services offered by the DCC SMETS1 Service. This could be the base case, where DCC provides the Minimum SMETS1 Services (37 Services), the as-is services currently supported by each SMSO (which in some cases would result in less than the Minimum 37 services); or the as-is services with a phased introduction to also implement the Minimum 37 services for all cohorts. Largely, these options affect the functionality provided to DCC users; however, some of the services relate to security management, such as the update of cryptographic keys, and these would be required to be provided to the meters under all communications services options. It will be necessary for the HES to have full access to the key management functionality within the meters. Provided the HES is able to utilise all security related service requests, then the Communication Services option selected would not affect the security risk Prepayment This aspect of the technical solution relates to the service to generate a UTRN for prepayment services, the sending of an OTA top-up request to device; and whether the interface used for requesting and receiving UTRNs is the same as, or different to, the SMETS1 DCC user interface. A number of UTRN generation options are identified as being feasible; in some of these options (Prepayment Options 1 and 2) the DCC provides a service to generate UTRNs, and in Prepayment Option 3 DCC provides a standardised generation function for energy suppliers to operate. The provision of the UTRN is critical to the pre-payment service, and the non-availability of UTRNs would affect the supply of electricity and/or gas to consumers. In SMETS2 systems, DCC does not have this risk as the energy suppliers undertake this functionality. This is equivalent to UTRN generation option 3. If UTRN generation options 1 or 2 are selected, then all or part of the prepayment solution operation would become part of the DCC Total System and the risk of a compromise to the availability of the service would increase. Depending on the existing implementations, additional controls to protect the UTRN availability, such as resilience, disaster recovery and protection against denial of service attacks may be required to ensure that there are equivalent controls to those implemented by DCC users. These increased availability requirements could be expected to increase the implementation costs compared to option 3, although this would not have a substantial effect on the overall whole-life cost. The other aspects of prepayment service do not affect the security considerations. IEPFR Consultation DCC Public Page 59 of 144

60 4.2.5 Implementation The security risk profile will have an impact on the implementation plan for DCC SMETS1 Services. Depending on the technical and security options selected, a range of security controls will need to be implemented within new systems or applied to existing systems. It will be important to ensure that the recommended security controls are in place prior to the capability to enrol all cohorts of meters going live, to ensure no increase in security risk. However whether all of the security controls need to be implemented in full at the initial operating capability, or whether a phased approach can be adopted, may depend upon the specific implementation path chosen. This is discussed in section Analysis of Security Options Section 4.1 and 4.2 identified a number of potential security options to address aggregated risk and ensure that there is no material increase in risk to the DCC Total System. The security options are not mutually exclusive; thus it is possible to use them in combination with each other SMETS1 CSP Limitations In this option the impact of compromise at the HES is reduced by limiting the simultaneous number of connections it can make to meters. This option would involve the application of network controls at the SMETS1 CSP. These controls are straightforward to apply and should be relatively low cost. This option aims to mitigate the impact of compromise, rather than the probability System Hardening The cost and technical viability for this option are strongly dependent on the systems to which the controls are applied. In a worst case scenario the application of the controls required by this option could require an existing system to be rebuilt. This option aims to mitigate the probability of compromise, rather than the impact Islanding There are no technical viability issues with creating a number of HES islands to reduce the number of meters that can be compromised by a single attack; however the more HES islands there are, the higher the build and management costs. In a similar manner to the SMETS1 CSP Limitations Option, this option aims to mitigate the impact of compromise. However, while it would have a similar effect on the residual risk to that achieved with the CSP limitations, there would be significantly higher costs and timescales associated it. This limits the feasibility of this control, and it is therefore proposed that the Islanding option is not adopted Enhanced Key Management If implemented with appropriate security, this option would create a dual organisational control, which would be a powerful security measure for mitigating risk at the HES. This control would reduce both the probability and the impact of compromise. In assessing the technical viability of this security option DCC has made a number of assumptions relating to the current use of cryptographic keys based on smart metering IEPFR Consultation DCC Public Page 60 of 144

61 standards. To fully appreciate the technical viability of this option, these assumptions will need to be tested Summary The implications of the majority of the security requirements identified in this document and their implications for cost, timescales, delivery confidence, and impact on functionality and users, have been taken into account in the overall option analysis in the evaluation tables in section 3 of this draft report. The security options analysed in this section represent additional activities that would need to be undertaken in addition to those set out in section 3. The impact of these activities is summarised in Table 10 below, which contains a high level comparison of the security options. Where appropriate, the implications of the security options on the different technical options are identified. The criteria used to assess the security options are the criteria set out in Appendix C with the addition of the following: Effectiveness, which relates to the potential of an option to mitigate security risk; and Impact of Technical Options, which relates to whether the different technical options affect the implementation of the security option. Criterion CSP Limitations System Hardening Islanding Effectiveness Medium Medium Medium High Enrolment Service Cost Timescales Low The network controls involved in this option should be relatively simple to implement. Faster than other security measures Higher than CSP limitations but lower than Islanding High Costs are estimated to range between 5m - 35m Cost will depend on the systems to which the controls are applied. Slower than CSP limitations The more HES there are the higher the build and management costs. Slower than CSP limitations Enhanced Key Management Higher than CSP limitations but less than Islanding There would be costs associated with both the implementation and managing a separate organisation. A number of assumptions have been made in assessing the cost of this option. Slower than CSP limitations IEPFR Consultation DCC Public Page 61 of 144

62 Criterion CSP Limitations System Hardening Islanding Delivery Confidence Impact on Functionality Impact on Users The network controls involved in this option should be relatively simple to implement. Timescales will depend on the systems to which the controls are applied. The more HES, the greater the potential impact on the timescales, due to the increased integration and testing required. Enhanced Key Management Interface to a separate organisation has the potential to impact timescales. A number of assumptions have been made in assessing the timescales associated with this option. High High High Lower than other options There are no significant issues that would affect the technical viability of this measure. Will be dependent on existing solutions, but rebuilding a solution is still technical viable. There are no viability issues with creating more HES. No impact No impact No impact No impact While there may be some impact on performance (e.g. a longer time to communicate with meters), there should be no impact on the functionality provided by the smart metering system, provided the implementation is suitably robust. While there may be some impact on the system and service management (which would affect the processes undertaken by system administrators and support staff), there should be no impact on the functionality provided by the smart metering system. While there will be some impact on the system and service management, (which would affect the processes undertaken by system administrators and support staff), there should be no impact on the functionality provided by the smart metering system. While there is no evidence that shows this option to be not technically viable some assumptions still need to be validated. While there should be no impact on the functionality of the smart metering system, there are a number of assumptions that need validation to confirm this. Low impact No impact No impact Low impact Possible impact on performance as the option may affect the time taken to process messages. There should be no impact on users. There should be no impact on users. No impact Some impact Less impact than Systems hardening and Enhanced Key Management, but more impact than CSP limitations Possible impact on performance as the option may affect the time taken to process messages. Some impact IEPFR Consultation DCC Public Page 62 of 144

63 Criterion CSP Limitations System Hardening Islanding Impact of technical options The different technical options do not affect this security option. Integration path 5 would result in potentially higher costs and timescales for this option compared to integration path 4, due to the number of legacy systems to which security controls would need to be retrospectively applied. This option would not be majorly influenced by the integration path selected, as the number of islands required would be independent of the integration path selected. Enhanced Key Management Integration path 5 would result in potentially longer timescales for this aspect of implementation compared to integration path 4, due to the number of legacy systems with which the enhanced key management operation would need to be integrated. 4.4 Security Conclusions Table 10 Showing a high level assessment of the security options DCC considers that with the appropriate application of security measures and security options it is possible to ensure that there is no material increase in risk to the DCC Total System, Enrolled Smart Metering Systems and User Systems as a result of DCC providing a SMETS1 Service. Additional costs and planning are required to ensure that there is no material increase in risk. The high cost and potential to impact timescales of Islanding limits the feasibility of this security option. However, a combination of the CSP Limitations, System Hardening and Enhanced Key Management options should be employed to ensure that there is no material increase in risk. The next steps arising from this analysis are to validate the assumptions made in analysing the security options, and in particular to: validate the assumptions made in the analysis of the enhanced key management option, and verify the feasibility of the enhanced key management process through a proof-of-concept options testing project; validate the impact on cost and timescales of hardening the legacy HES if required (where relevant to the technical options selected); and validate the impact on cost and timescales of applying the CSP limitation controls if required. 4.5 Consultation Questions Consultation Questions: Security 25 Do you agree with the approach set out in section that DCC has adopted for assessing a material increase in risk? Please provide a rationale for your views. IEPFR Consultation DCC Public Page 63 of 144

64 Consultation Questions: Security 26 Are there any security option areas or significant measures which have not been outlined in section that you would consider of key importance to a SMETS1 solution? Please provide a rationale for your views. 27 Are there any additional security issues that would need to be taken into account when assessing the technical options described in section 4.2? Please provide a rationale for your views. 28 Do you have any comments on the feasibility of implementing the identified security options? Please provide a rationale for your views. IEPFR Consultation DCC Public Page 64 of 144

65 5 Service Delivery 5.1 Service Management and Service Desk Context Service Management is a key aspect of DCC services it is the function that provides day-to-day communication and support to users through the Service Desk and protects service availability and performance by ensuring that any issues with DCC services are addressed within the parameters set out in the SEC. Accordingly, in this section DCC has analysed the feasibility of providing Service Management for each of the technical and security options outlined in sections 3 and 4. DCC has not, however, developed detailed cost comparisons as our cost model shows that Service Management represents between 2% and 4% direct DCC cost of the lifetime cost of SMETS1 and therefore is not material to the evaluation of options. In the consideration of Service Management DCC has analysed both the user facing aspects of Service Management and the internal DCC systems and processes which DCC uses to interface with its service providers. The user-facing aspects of Service Management are set out in the SEC and cover Service Management, Service Desk, Incident Management and Business Continuity. The SEC requires that the Service Management Standards used throughout DCC (including its service providers) should be aligned with the internationally-accepted ITIL framework but is otherwise silent on DCC s internal operations. In section 3, technical options are identified and assessed against criteria. In contrast, the analysis in this section focuses on assessing the level of alignment between the Service Management and Service Desk arrangements of the service providers that may be involved in delivery of the DCC SMETS1 Service (existing and new) and the current Service Management and Service Desk arrangements provided by DCC under the SEC in relation to SMETS2 service provision. This is because: the DCC Service Desk is already the single point of contact for DCC users, with a number of clear obligations on DCC and users set out in the SEC, including use of the Self-Service Interface. This single point of contact with DCC for service users should be retained for both SMETS1 and SMETS2 meters, giving ease of use to service users and avoiding the need for users to differentiate as to whether an issue relates to the SMETS1 or SMETS2 Service when making contact with DCC; the resources and technology employed in providing the Service Desk and Self- Service Interface are already available to DCC and are not limited to SMETS2; and the IT Service Management tooling used by DCC and service providers is largely based on industry standard technology and is agnostic to the nature of the users and systems being supported. Analysis does not therefore lead to radically different technical solutions specific to SMETS1 meters or individual cohorts of SMETS1 meters, but rather to choices about use and configuration of tooling that should be invisible to end users. The analysis indicates that, for the current SMETS1 arrangements, suppliers and their service providers do not have a common approach to Service Management, Service Desk, Incident Management and Business Continuity. It may be necessary therefore to refine DCC s internal approach to Service Management where it contracts with incumbent IEPFR Consultation DCC Public Page 65 of 144

66 SMETS1 Service providers to effectively integrate that service management capability with DCC s existing capabilities. The options and extent of the modifications required for DCC to manage both the SMETS2 and SMETS1 Services are set out in the following sections Service Management In order to maintain the efficient operation of DCC Service Management, DCC considers that the Service Management approach for the DCC SMETS1 Service should align with that already established for SMETS2 as far as possible. The Service Management Standards (ITIL) are broadly supported across the current SMETS1 service providers, albeit with different interpretations and to different extents. The key elements of Service Management to be considered are Resolver Groups, which determine their interaction with DCC, and the SMSO s Service Management approach which demonstrates their level of Service Management maturity. Resolver Groups When an Incident is raised with the DCC Service Desk, the Incident will be assigned to a Resolver Group for investigation and resolution. Under all technical options, all of the service providers directly contracted to DCC would become new resolver groups. This could include: SMSOs; SMETS1 CSPs; and any new DCC SMETS1 Data Services Provider. Where the SMSO contracts with the SMETS1 CSP, the SMSO will be the single resolver group for both data and communications services. Service Management Approach SMSOs do not have a common approach to Service Management. The Service Management Approach is internal to the SMSO s organisation and only impacts DCC s operation in the areas of Incident Management and the Service Management Tool which are dealt with below. As the internal SMSO operation has minimal impact on DCC, DCC would take SMSOs' services 'as-is', with no enhancements to their current Service Management capabilities. DCC considers that any new DCC service providers contracted to provide elements of the SMETS1 Service should be required to comply with the Service Management Standards, irrespective of the technical options selected Self-Service Interface The DCC Self-Service Interface (SSI) provides DCC users with access to information and services designed for SMETS2 meters and the enduring DCC service. Not all SSI use cases would be applicable to DCC enrolled SMETS1 meters and the DCC SMETS1 Service and, for some of those that are applicable to SMETS1, there will be an impact on the design of the SSI or the data sources with which it is integrated. IEPFR Consultation DCC Public Page 66 of 144

67 DCC considers that users with DCC enrolled SMETS1 meters should have the ability to self-serve to the same extent as for SMETS2 meters, subject to the technical constraints outlined above. DCC considers that the obligation on users to attempt to self-diagnose prior to raising an Incident should be extended to DCC enrolled SMETS1 meters. The DCC Service Desk is the single point of contact for SMETS2 services for SEC Parties and Registration Data Providers. As outlined above, a number of additional service providers will be introduced to DCC as a result of providing a SMETS1 Service. DCC considers that existing service providers' service desks should cease to act as a point of contact for users in respect of DCC enrolled SMETS1 meters. Instead the DCC Service Desk should provide these services in respect of DCC enrolled SMETS1 meters, under the same terms set out in section H8.19 of the SEC. This enables: a single point of contact for both the DCC SMETS1 and SMETS2 Services this will become increasingly relevant over time, as meters churn away from the installing supplier, potentially to suppliers with no relationship with the relevant service providers. Service users will not need to spend time determining the type of meter and potentially contacting many Service Desks to resolve issues; a consistent user experience when seeking support, regardless of the meter type or service providers involved (where the mix of service providers will be determined by the technical options selected and some existing service providers may not be included); and a controlled and manageable set of Service Desk procedures, such that DCC can measure and ensure adherence to relevant service levels for call handling etc Incident Management Incident Management Section 1.4 of the DCC Incident Management Policy requires that Incidents are raised and recorded (by an Incident Party or by DCC) in the Incident Management Log and lists in order of preference the methods by which Incidents may be added to the Log. Sections 2.2 and 2.3 define the pre-requisites and obligations on Incident Parties and DCC in respect of raising and updating Incidents. DCC considers that there should be no change to these sections as a result of enrolment of SMETS1 meters with DCC. Section 2.4 of the Incident Management Policy sets out DCC's obligations in respect of prioritising and categorising Incidents. The Categorisation Matrix in this section defines 5 Incident Categories and their respective Initial Target Response Times and Target Resolution Times. Whilst Incident Categories are described in generic terms and need not distinguish between SMETS2 and DCC enrolled SMETS1 meters, the service providers currently involved in the delivery of SMETS1 data and communications services may not currently align with the Initial Target Response Times and Target Resolution Times. IEPFR Consultation DCC Public Page 67 of 144

68 In order for the DCC SMETS1 Service to comply with the Initial Target Response Times and Target Resolution Times, where existing service providers are used by DCC, it would be necessary to align those service provider arrangements with the SEC. This activity would need to be subject to a cost-benefit analysis. DCC considers that any new DCC SMETS1 Data Service Provider should be required to comply with the Target Response and Resolution Times set out in the SEC, irrespective of the enrolment option(s) selected. Error Handling The DCC Error Handling Strategy guidance document sets out the actions that DCC users should take when Errors are encountered. The Error Handling Strategy defines five categories of Error and lists the relevant procedures under each category. In DUIS, each Error Response Code has a cross reference to the corresponding Error Handling Strategy procedure. DCC does not anticipate changes to the Error categories for the SMETS1 Service, but new Error Response Codes may be added for SMETS1 meters, which in turn would lead to new Error Handling Strategy procedures for those Errors. Service Management System The DCC Service Management System (SMS) is the tool which supports the DCC Service Desk and provides interfaces to users and service providers for the raising and management of Incidents. The DCC SMS is provided by the DSP and incorporates the Incident Management Log referred to in section 1.4 of the Incident Management Policy. DCC users interact with the SMS via the Self-Service Interface (see section 7.6.4), whereas the DCC Service Desk and DCC service providers interact with the Service Management System via the Remedy user interface and a variety of other channels. There are, therefore, two methods by which SMETS1 service providers (who would become resolver groups in the DCC Service Management System) could interact with that system: DCC creates system interfaces to integrate DCC Service Management System with SMETS1 service providers' service management systems such that DCC Service Management Records may be viewed, created and updated. This option requires SMETS1 service providers to change their systems to permit integration of their service management systems with the DCC Service Management System. SMETS1 service providers become users of the DCC Service Management System to view, create and update Service Management Records, maintaining their own service management records in separate systems without a system interface to the DCC Service Management System. In this option, there may still be system interfaces for service providers' monitoring systems to automatically create Incidents in DCC Service Management System. IEPFR Consultation DCC Public Page 68 of 144

69 5.2 Evaluation against Criteria Table 11 below contains an evaluation of Service Management System options against the criteria defined in Appendix C. This evaluation shows that either alternative would provide an adequate Service Management System without material impact on the lifetime cost model. This evaluation will be refined during the next phase of the project. Criteria Integrate with service provider management systems Service providers use DCC Service Management System Enrolment Service Costs Timing Potential significance of option cost to whole life cost: Low There would be costs associated with integrating SMETS1 service provider service management systems, however these should not be material to the whole life cost, hence this option does not have a material effect on the enrolment service costs. This option is likely to have a higher initial cost than using the DCC Service Management System. This option also should not have a material effect on the enrolment service costs. SMETS1 service provider costs for ongoing service delivery are likely to be higher for this option due to the need for service providers who become users of the DCC Service Management System to adopt new tools and processes. This option has no material impact on timing through build and test or commercial activity. DCC build the new SMETS1 data system which is still the major component of the build and test phase. Delivery Confidence Functionality This option requires the highest degree of change to SMETS1 service provider systems and is more technically complex for DCC. SMETS1 service providers whose systems are to be integrated with the DCC Service Management System would also be required to implement technical changes. SMETS1 service providers would continue to use their own service management systems, therefore the level of process and organisational change would be lower for this option. Functionality of SMETS1 service provider systems would be mapped to functionality of the DCC Service Management System. Detailed analysis may highlight gaps to be closed, but Incident Management workflows are a common and widely available feature, so it is reasonable to assume that full functionality can be delivered. This option requires the least system change for both DCC and service providers. The DCC would need to configure resolver groups and workflows but not integrate SMETS1 service provider systems. Similarly there is less technical change to SMETS1 service provider service management systems. SMETS1 service providers would need to make process and organisational changes to adopt the DCC Service Management System. The Service Management System has been configured according to DCC assured design specifications and therefore suitable Incident Management functionality is known to exist. Impact on Users Nil this is a non-user facing option. Users interact with the DCC Service Management System via the Self-Service Interface and Service Desk. Downstream systems are not visible to users. Table 11 Service Management System options Relative Advantages and Disadvantages IEPFR Consultation DCC Public Page 69 of 144

70 5.3 Business Continuity Section H10 of the SEC sets out requirements for DCC to comply with the requirements for Business Continuity and Disaster recovery. The Business Continuity and Disaster Recovery provisions of existing SMSOs are not wholly consistent with the requirements of section H10 of the SEC or with the DCC Business Continuity and Disaster Recovery Procedures set out in the DCC Incident Management Policy. Should integration path option 5 ( integrate to SMSO ) be selected, to ensure that the DCC SMETS1 Service complies with the applicable BCDR requirements set out in the BCDR Procedures, it would be necessary to align service provider contracts with the requirements, subject to a cost-benefit analysis. DCC considers that any new DCC SMETS1 service provider should be required to comply with the BCDR Procedures (subject to cost-benefit analysis), irrespective of the integration path option(s) selected. 5.4 Consultation Questions Consultation Questions: Service Delivery 29 Do you agree that a single Service Desk and single Self Service Interface should be provided for SMETS1 and SMETS2? Please provide a rationale for your views. 30 Do you agree that any new SMETS1 service providers should conform to the Service Management Standards? Please provide a rationale for your views. 31 Do you agree that any new SMETS1 service provider should comply with the Initial Target Response Times and Target Resolution Times for Incidents required by the SEC? Please provide a rationale for your views. 32 Do you agree that the same level of self-diagnosis tools should be provided to users for SMETS1 as those for SMETS2? Please provide a rationale for your views. 33 Do you agree with the proposed approach to Business Continuity and Disaster Recovery? Please provide a rationale for your views. 34 Do you agree with the analysis of options for the Service Management System? Please provide a rationale for your views. IEPFR Consultation DCC Public Page 70 of 144

71 6 Commercial Approach 6.1 Context and Structure of this Section In sections 3 and 4 of this report an overview is provided of the technical and security architecture necessary to enable the provision of a SMETS1 Service by DCC. At this stage of the project, the emerging commercial approach needs to support a range of potential delivery options identified in those technical and security sections. Current commercial arrangements for SMETS1 meters consist of one or more contracts held by suppliers. Figure 15 below presents a simplified view of these different types of commercial arrangements. In some instances suppliers have contracted with one party for the provision of both data and communications services (a bundled service) (number 1 in figure 15). In other instances energy suppliers perform their own data services function and contract separately for communications services (number 2 in figure 15). In the third set of arrangements, contracts have been separately placed for data and/or communications services (number 3 in figure 15). Where a bundled contract exists, in all instances the counterparty (i.e. the SMSO) has separately sub-contracted for the provision of communications services. 1 SMETS1 CSP Services SMSO Energy Supplier 2 SMETS1 CSP Services Energy Supplier 3 SMETS1 CSP Services SMSO Energy Supplier Figure 15 Summary of Existing Commercial Arrangements The high level commercial challenge for DCC is to develop a commercial strategy that will support the economic and efficient development, implementation and on-going support of a DCC SMETS1 Service without adversely impacting on the SMETS2 Infrastructure. In developing and implementing this commercial strategy, DCC needs to: ensure the timely delivery of a DCC SMETS1 Service; and fulfil licence commitments to promote value for money, non-discrimination and transparency throughout the procurement and contract management activities. IEPFR Consultation DCC Public Page 71 of 144

72 Accordingly, this section of the report sets out: the emerging high level view of the services that will need to be procured; the options available to DCC for the procurement of these services, including the capability and feasibility of DCC adopting existing arrangements for communications services; DCC s procurement strategy and approach; an overview of emerging commercial considerations regarding the negotiation of SMETS1 service provider contracts; anticipated timelines for the procurement of the services required; and DCC s view of delivery confidence for the various contractual arrangements required. The commercial arrangements that are required in the SEC to support the provision by DCC of a SMETS1 service to users are set out separately in section 9. DCC has also submitted to BEIS a document that sets out in more detail DCC s commercial analysis to date. However this information has not been published in this draft report, due to commercial confidentiality concerns or to prevent undermining any future commercial negotiations that DCC undertakes. Consistent with section N of the SEC, the term adoption is used in this section to describe the process of novation (with amendment) of the existing arrangements that energy suppliers have in place for SMETS1 communication services. The term novation is used in this section to describe the process of novation (with amendment) of the existing arrangements that energy suppliers have in place for SMETS1 data services. 6.2 Summary of Procurement Requirements The services that DCC will have to procure, in order to provide a DCC SMETS1 Service, are set out in the table 12 below. Where procurement requirements vary depending upon the technical or security option chosen, this is also indicated: Topic Capability required under any option Capability required if particular option chosen Integration path SMETS1 DCC user interface Management of service requests and responses, translation, hosting, communications network. N/A If integration path 4 is chosen ( integrate to meter ), a new HES provided by DCC and a communications management function will also be required. If integration path 5 is chosen ( integrate to SMSO ), DCC will procure services from incumbent SMSOs that deliver the HES and communications management functionality. Option 1 changes to existing SMETS2 DSP contract to extend current DCC user interface to support SMETS1 service requests. IEPFR Consultation DCC Public Page 72 of 144

73 Topic Capability required under any option Capability required if particular option chosen Communication Services (service requests) Prepayment N/A Development of UTRN generation capability. Options 2 and 3 newly hosted SMETS1 DCC user interface and new connections to that interface. Option 1 and 2 changes to DUIS schema to be developed. Option 3 new SMETS1 schema to be developed. The specific communication services option chosen combined with the choice of integration path will determine the scope of services to be procured. There are three options under consideration for communication services (set out in section 3.3. One option requires, if integration path option 5 ( integrate to SMSO ) is chosen, the procurement of platform upgrades from some SMSOs to enable full support for the minimum SMETS1 Services. If integration path option 4 ( integrate to meter ) is chosen this same option results in the procurement of a new system that can support the minimum 37 services. Another option takes existing SMSO services as is (only a relevant option if integration path option 5 ( integrate to SMSO ) is chosen). The third option is a hybrid of the two above, which will necessitate the procurement of platform upgrades over time (again, this is only a relevant option if integration path option 5 ( integrate to SMSO ) is chosen). Options 1 and 2 - development of DCC interface for requesting/sending UTRNs. Option 3 - development of externally implemented software plus associated support. Security Controls A number of different security controls are considered in section 4. The extent to which all of them are required in part depends upon the integration path adopted and (where integration path 5 is adopted (integrate to SMSO)) the existing security controls that are in place. Procurement requirements could include a new PKI (or changes to SMKI), a key management organisation, anomaly detection, prevention and protective monitoring. Service Management Extend existing DCC service management systems to encompass SMETS1. N/A 6.3 Procurement Options Table 12 Services DCC will have to procure DCC will need to combine three types of commercial arrangement to provide the enabling commercial structure to support delivery of the DCC SMETS1 Services: IEPFR Consultation DCC Public Page 73 of 144

74 procurement of new capability; DCC will need to procure new services the range and complexity of which is dependent on future decisions and on-going analysis of options; procurement of existing SMETS1 service provider communications and/or data services capability: In the case of communications, DCC will need to procure capability from existing SMETS1 CSPs. In the case of data services, where integration path option 5 ( integrate to SMSO ) is implemented (integrate to SMSO), DCC will need to procure capability from existing SMSOs. The SEC requires DCC to consider the adoption of existing arrangements for communications held by suppliers. DCC has also considered the potential to novate other elements of supplier party contracts for data services. However in both cases, there is also the option to put in place new arrangements with the incumbent service providers; and changes to existing DCC services: DCC will also need to make changes to existing DCC services to integrate with new DCC SMETS1 functions. However the extent of the changes depends upon the options selected. Additionally, consideration is required of the transitional arrangements that will need to exist whilst SMETS1 meters are in the process of being migrated to DCC Procurement of New Capability DCC may need to procure new capability in a number of areas, which includes: request management of service requests and responses, hosting, translation and communications management; the application of certain security controls; UTRN generation; the provision of a DCC user interface (if either SMETS1 DCC user interface option 2 or 3 is chosen); and the development of a new SMETS1 message format (if SMETS1 DCC user interface option 3 is chosen). As set out previously, the scope of the services to be procured and the number of new contracts required are dependent on design decisions. At this stage DCC hass not identified how many contracts will be let and how these will be structured. DCC expects to complete this commercial design work in the next phase of the project Procurement of Existing SMETS1 Service Provider Capability: Communications Arrangements (including feasibility of Adoption) Requirement to Assess Feasibility of Adoption N4.4 (b) of the SEC requires DCC, as part of the IEPFR, to consider the feasibility of adopting energy suppliers existing arrangements for communication with SMETS1 meters, with or without amendment. It states that the IEPFR must include: The DCC s: assessment of the Communications Contracts against the Adoption Criteria, and of IEPFR Consultation DCC Public Page 74 of 144

75 whether some or all of the Communications Contracts should be Adopted, and of whether those that are to be Adopted should be amended or consolidated following their Adoption. The SEC also requires DCC to specify the adoption criteria that it will use to, in part, assess the feasibility and cost of adoption. Communications Contracts are defined in the SEC as: the contract or contracts (or the relevant parts thereof) pursuant to which the Supplier Party has (or, will following installation, have) the right to receive communication services in respect of that Energy Meter. Contracts within scope of this requirement therefore are the primary contractual relationships by which energy suppliers obtain their SMETS1 communication services. Where an energy supplier has contracted for a bundled SMETS1 Service for both data and communications, and the counterparty to that contract has separately sub-contracted for communications services, DCC is required to assess the feasibility of adopting the arrangements for communications services that exist in the primary contract, not the subcontract. Appendix F describes the approach that DCC has taken to assessing the feasibility of adopting existing communications arrangements. DCC has sought to obtain copies of existing commercial arrangements that are in place for SMETS1 communication services. Additionally DCC has also sought to elicit relevant information through Commercial Clarification Questions (CCQs) that are based on DCC s adoption criteria. Analysis of Feasibility of Adoption In assessing the feasibility of adopting existing arrangements for communication services, DCC needs to consider a number of factors. These include whether suitable novation terms exist, and the likelihood of securing necessary amendments to the contract as part of the adoption process on suitable commercial terms. DCC has assessed sixteen separate arrangements for communications that are in place and DCC s current view of the feasibility of adoption has been either been formed on the basis of: the existing signed contract that is in place; or responses to CCQs and on-going dialogue with energy suppliers and/or their SMETS1 CSP (sometimes supplemented with draft or unsigned contracts). Where DCC s view has not been formed on the basis of existing contracts, DCC will continue its engagements with energy suppliers and their service providers to source copies of the actual commercial arrangements that are in place. In relation to the contract that DCC has assessed, DCC s preliminary view is that adoption of this contract is feasible and could be adopted. However further discussion is required on how adoption can be accommodated given the contract structure, which is in part based on a framework agreement that would need to be retained for a number of other contractual arrangements that DCC would not be seeking to adopt. IEPFR Consultation DCC Public Page 75 of 144

76 In relation to the assessment that DCC has performed on the other fifteen cases DCC s preliminary view is as follows: in six cases adoption may be feasible. Either the energy supplier has separately contracted for SMETS1 communication services, or where a bundled contract has been struck for both data and communications services, the contracts have been structured in such a way that adoption of the commercial arrangements by DCC can be accommodated. However before a more definitive view can be provided, DCC would have to review the contract to confirm the actual commercial arrangements in place; and in nine cases adoption is unlikely to be feasible either because: the current arrangements represent the provision of a bundled service for both data and communications and DCC understands that the contracts have been structured in a way that would make the task of unbundling the communications elements complex; the current arrangements support the provision of multiple services, not just data and communications services to support SMETS1, and the restructuring of the contract to only relate to SMETS1 Service provision would be difficult; or the current arrangements are governed only by Heads of Terms. In all of the above cases where adoption has been indicated as feasible, its feasibility is also contingent upon DCC being able to secure amendments to the contracts to reflect satisfactory contract terms in relation to matters such as IPR, liabilities, mandatory licence requirements and the length of the contract (as further set out in 6.5 below). Additionally, where the security controls which would seek to limit the number of simultaneous connections between a HES and the SMETS1 CSP network needs to be implemented (described in section 4), this would also require amendment to the contract terms. Alternative Approaches to Adoption The alternative to adoption of the existing communications arrangements is for DCC to seek to put in place alternative contractual arrangements with the existing SMETS1 CSPs. DCC considers this to be a feasible alternative, noting that the approach that it would have to undertake in relation to key terms such as IPR, liabilities, mandatory licence requirements, contract term and security controls would be the same as that for adoption. Whether adopting existing arrangements for communications services from energy suppliers, or negotiating new contracts for communication services where the SMETS1 CSP is the same, DCC will seek to consolidate arrangements so that it has a single contract in place (in the case of adopted contracts this consolidation may take place after adoption). DCC considers that this will enable DCC and the supplier of communication services to make best use of economies of scale, thereby fulfilling DCC s licence commitments to promote value for money. Further Analysis and Next Steps As previously stated, the information with respect to the feasibility of adoption represents the latest position in an on-going process of due diligence. In the next phase of the project this information will continue to be refined as follows: IEPFR Consultation DCC Public Page 76 of 144

77 subject to the successful outcome of the current consultation on changes to section N, DCC may request suppliers to provide further information (including contracts) relating to existing arrangements for communication services; DCC will further consider whether it should adopt the existing arrangements for communications where adoption proves feasible; more detailed analysis will be undertaken of the current market arrangements and strategies for sourcing each of the relevant agreements; and DCC will assess the potential of a DCC SMETS1 Service on DCC existing operations (operationally and with respect to DCC s change capacity) and the formulation of necessary measures to address the impact Procurement of Existing SMETS1 Service Provider Capability: Data Services Arrangements If integration path 5 (integrate to SMSO) is chosen, DCC would need to continue to procure capability from existing SMSOs for data services. Two options exist for the procurement of this capability; novation of the existing contractual arrangements that energy suppliers have in place or the putting in place of new contract terms. As is the case with adoption, where DCC seeks the novation of existing commercial arrangements for data services, this would be contingent upon DCC being able to secure amendments to the contracts to reflect satisfactory contract terms in relation to matters such as IPR, liabilities, mandatory licence requirements and the length of the contract. Additionally where further SMSO functionality enhancements and security controls are required to be implemented (as described in section 4), this would also require amendment to the contract terms that are novated. The alternative to novation of the existing SMSO contracts arrangements is for DCC to seek to put in place new contractual arrangements with the existing SMSOs. Under this approach, DCC would still have to secure satisfactory outcomes with respect to key terms such as IPR, liabilities, mandatory licence requirements, contract term and security. However the ability to do so is also contingent upon the incumbent SMSO wishing to continue to provide these services, albeit to DCC. This means that integration path option 5 ( integrate to SMSO ) is only viable where these contractual arrangements can be secured. DCC considers that in certain circumstances, entering into new contractual arrangements is preferable, rather than the novation of existing contract terms for data services. This is because the existing contracts include a number of services other than the provision of data services which energy suppliers have informed DCC would be difficult to disaggregate. DCC therefore considers that a new contract for such on-going SMETS1 data services would be easier, and more desirable to conclude Changes to existing DCC services DCC s existing contractual arrangements to support the provision of SMETS2 services may, dependent on future decisions, also require changes to support SMETS1. Specifically DCC may need to amend the following arrangements: the DCC user interface (should SMETS1 DCC user interface option 1 be adopted); and IEPFR Consultation DCC Public Page 77 of 144

78 the SMKI services (should SMKI be used for the purposes of applying certain PKI security controls). Additionally DCC will need to amend its service management arrangements (as set out in section 6.5). The exact nature of the changes required has not yet been identified. DCC expects to complete this work in the next phase as part of the commercial design SMETS1 Transitional Arrangements Energy suppliers may need to ensure that appropriate commercial arrangements are in place with each of their incumbent service providers to provide appropriate transitional arrangements should they plan to enrol their SMETS1 meters with DCC. For example, where contracts are novated to/adopted by DCC, energy suppliers will need to ensure that it also has arrangements in place to support their existing SMETS1 solution, until the enrolment of their last SMETS1 meter with DCC. 6.4 Procurement Strategy and Approach DCC s licence, which is reflected throughout DCC s procurement strategy, promotes value for money as a key consideration in any procurement exercise alongside equality and transparency. In particular: DCC Licence Conditions Principles 2 and 4 of Condition Principle 2 is that Relevant Service Capability must be procured competitively wherever practicable and proportionate, and with due regard for (i) the principles of equality and non-discrimination between economic operators and (ii) the employment of transparent and objective procurement processes Principle 4 is that Relevant Service Capability must be procured in a manner that: secures value for money in terms of the combination of quality and cost over the lifetime of the contract; delivers the required goods, services, or works to the appropriate standards according to the needs of service users; takes account of the potential need to replace from time to time the persons engaged in providing the capability; and incorporates (at a cost that is not disproportionate to any expected benefit) sufficient flexibility to adapt to changing service user requirements over the duration of the contract. DCC has formed a preliminary view on how it may secure value for money in the arrangements that it procures to support the provision of a SMETS1 Service. Detailed approaches to procurement and securing value for money will be developed as part of the on-going commercial design. IEPFR Consultation DCC Public Page 78 of 144

79 6.5 Commercial Considerations for Design As part of the negotiation leading to agreement of new contracts or adoption or novation of relevant existing contracts there are a number of key areas that will need to be considered. Set out below are those areas identified to date. These and other emerging issues will be considered in detail as part of the commercial design in the next phase of the project Contractual terms required to comply with the Licence Under the DCC Licence, DCC is required to ensure that certain conditions and requirements are incorporated into all of its contracts with external service providers. SMETS1 communications arrangements ( communications contracts ), which are adopted, will need to be amended to meet this requirement, as will any other novated contracts or new contracts let to provide capability required to deliver the DCC SMETS1 Service. DCC has undertaken a review of its Licence and identified where a relevant provision or requirement may need to be included. These include, but are not limited to, provisions that require the service provider: not to operate in a way that would prejudice DCC s general objectives under its licence; not to operate in a way that would put DCC in breach of its licence or the SEC; grant permission to DCC to disclose confidential information where it is required to do so under its licence; and have in place arrangements that support any revocation/handover of DCC licence to a successor Contract length DCC expects SMETS1 arrangements to continue for the anticipated life of the meters, DCC needs to consider as part of the design how service provider contracts are structured to support this anticipated life and any implementation strategy (discussed further in section 7) which might be selected Intellectual Property Rights (IPR) Subject to condition 44 of its licence, DCC is required to ensure appropriate regard for the potential impact of IPR ownership and licensing on effective competition, future integration of services under or pursuant to the SEC and the rights of any external service provider or successors to be able to use essential IPRs created or held by any of their predecessors. Additionally, condition 44.8 states: The Licensee may not be party to any External Service Provider Contract under or pursuant to Condition 16 that does not expressly provide for the Licensee to license any successor to the External Service Provider to use such IPRs arising from that contract as are necessary to enable the successor to secure an orderly transfer of the effective provision of Relevant Service Capability under the contract on terms that are not IEPFR Consultation DCC Public Page 79 of 144

80 materially disadvantageous relative to those applying previously. Information gathered through the CCQs and analysis of available contracts indicates that in the case of existing SMETS1 commercial arrangements there is a varied approach to the transfer or licensing of IPR for Intellectual Property relating to the contract. As part of the commercial design DCC will need to consider how to ensure that any resultant contracts are in line with its Licence requirements. This is in addition to ensuring that new contracts procured are similarly aligned Liabilities and Dispute Resolution The contractual terms governing DCC s provision of SMETS1 Services would be set out in the SEC (as they are for SMETS2). A set out earlier, DCC will need to contract for the provision of a number of services that enable it to provide the SMETS1 Service. As a result, DCC will need to ensure that the contractual terms in the SEC and those with its sub-contractors are aligned where this is appropriate. Examples of such considerations are that the SEC places a 1m limit on liabilities in relation to damage to physical property. Additionally, liabilities for breach of IPR and, in certain circumstances, confidentiality are unlimited (although certain types of loss are excluded). Initial analysis against adoption criteria of contracts which may be subject to adoption or novation indicate thata range of liabilities have been included. As part of the commercial design DCC will need to review the liability clauses of relevant contracts and identify mechanisms for aligning terms with those set out under the SEC. This is in addition to ensuring that new contracts procured are similarly aligned. Provisions also need to be made in any contracts that DCC enters into that provide mechanisms to enable effective resolution of disputes between DCC and SEC parties on the one hand, and DCC and its service providers on the other, where the disputes arising are in relation to the same matter. This joining of disputes is already provided for under the SEC in relation to SMETS2 services Change Management SMETS1 contracts let by DCC need to recognise the regulatory environment in which DCC operates, particularly the change management arrangements under the SEC. Service provider contracts needs to be struck in a way that enables timely and efficient delivery of future changes that are required to support changes made under the SEC. As part of the commercial design in the next phase, DCC will consider change management and potential supporting contractual terms in light of lessons learned from SMETS Procurement Timescales Procurement is a key stage in the establishment of a DCC SMETS1 Service. As detailed in the earlier sections, the services that need to be procured are sensitive to a number of decisions. While some elements of the commercial design can be undertaken in parallel to other project activities, ultimately procurement is dependent on the following activities: completion of the majority of the high level design, so that tender documentation can be completed; and IEPFR Consultation DCC Public Page 80 of 144

81 understanding the approach to implementation, so that the procurement lots and requirements are specified in a way that supports it. DCC anticipates that any new capabilities that it procures to support its provision of a SMETS1 Service will be classified as Relevant Service Capability (RSC) (as per the DCC Licence). The guidelines set out in DCC s procurement strategy for competitive procurement of a RSC (including Fundamental Service Capability) indicates the use of a full tendering process, details of which can be found in DCC s published procurement strategy. DCC has formed a provisional view of possible procurement timescales, based on the information that is currently known. It must be stressed that this is a very early view and should be treated as such. Procurement timescales cannot be stated with a good degree of confidence at present, given that DCC is only at the feasibility stage of this project. Anticipated timescales for the procurement of various capabilities are set out in the table below (table 13): Topic Capability required Anticipated timescales Comments New SMETS1 data services Integration path 4 (integrate to meter) with new contracts for communications Integration path 4 (integrate to meter) with adopted communications arrangements Management of service requests and responses and hosting. Where integration path 4 is adopted (integrate to meter), this will include a new HES and communications manager. Where integration path 5a is adopted, this will include an SMSO translation function. Communications networks Communications networks 9-12 months Length of time to procure RSC per DCC s procurement strategy. Expansion of capability if integration path 4 is adopted is not assumed to change procurement timescales months Length of time will vary on a cohort by cohort basis, depending upon the level of engagement to date and the time it may take to negotiate with individual service providers ranging across 3 6, 9 or months months Length of time will vary on a cohort by cohort basis, depending upon the level of engagement to date and the time it may take to negotiate with individual service providers ranging across 6, 9 or 12 months. Further complexity introduced as in some scenarios the contract to be adopted contains terms for both data and communication services but data services no longer required. Integration path Existing HES, 3-12 months Length of time will vary on a cohort by IEPFR Consultation DCC Public Page 81 of 144

82 Topic Capability required Anticipated timescales Comments 5 with new SMSO and/or new communications contracts Integration path 5 with adopted communications arrangements and new contracts SMETS1 DCC user interface option 1 SMETS1 DCC user interface options 2 or 3 Security Security Security Prepayment option 1 and 2 Prepayment option 3 communications manager and communications networks Existing SMSO HES, communications manager and communications networks Amendments to DCC user interface (SMETS2 DSP) to be used for SMETS1 service requests and to define structure for SMETS1 service requests Hosting of SMETS1 DCC user interface plus define structure for SMETS1 service requests Amendment of SMKI (if required) for use in relation to SMETS1 service requests Procurement of new PKI solution (if required) Procurement of Key Management Organisation Development of UTRN generation capability and DCC interface for requesting/sending UTRNs (assuming a separate interface to the SMETS1 DCC user interface) Option 3 - development of externally implemented software plus associated support cohort basis, depending upon the level of engagement to date and the time it may take to negotiate with individual service providers ranging across 3, 6, 9 or 12 months months Length of time will vary on a cohort by cohort basis, depending upon the level of engagement to date and the time it may take to negotiate with individual service providers ranging across 3, 6, 9 or 12 months. Up to 12 months Based on SMETS2 experience 9-12 months Length of time to procure RSC per DCC s procurement strategy 3-6 months As an existing service provider, prior knowledge of DCC s requirement should allow for a more timely procurement than for a third party. 6-9 months SMKI took 6 months to procure, so replicated this timeframe. 6-9 months SMKI took 6 months to procure, so replicated this timeframe. 3-6 months Similar scale of procurement to GIT for Industry procurement with similar complexity. 3-6 months Similar scale of procurement to GIT for Industry procurement with similar complexity. IEPFR Consultation DCC Public Page 82 of 144

83 Topic Capability required Anticipated timescales Comments Service Management Amend existing capability to extend service management regime to encompass SMETS1 6-9 months Capita and SMETS2 DSP contracts require amendment. Table 13 Provisional view of possible procurement timescales 6.7 Commercial Delivery Confidence DCC considers that suitable commercial arrangements can be put in place that would enable DCC to deliver a SMETS1 Service. The scope of the contracts that DCC needs to put in place varies, depending upon which technical and security options are chosen. The number of contracts that DCC needs to put in place varies also, depending upon how capabilities are procured. For example: in order to support an integration path 4 solution, DCC will need to contract for a number of new data services including request management and a new HES and will need to contract for communication services. Where these capabilities are procured separately, the contracts will need to be structured in such a way that enables the various service providers to interact with each other; and in order to support an integration path 5 solution, DCC will still need to contract for new data services, but with a narrower scope as some data service functions (namely the HES and the communications manager) would be procured from existing SMSOs. DCC would have to structure the contracts to enable the new data services provider and the existing SMSOs to interface with each other. A further consideration is whether DCC should be required to adopt the existing arrangements for communications. In this scenario, where the existing communications are provided as part of a bundled service by an SMSO, novation of the entire contract might be preferable, rather than adopting communications arrangements and separately procuring data. Additionally, though capabilities might be separated into lots for procurement purposes, this does not necessarily prevent the same service provider from successfully tendering to provide more than one lot. The outcome of the procurement will therefore also affect the nature of the commercial relationships and interfaces that are required to be put in place. DCC s view of commercial delivery confidence does not vary between options where new capabilities are being procured that are currently not provided (for example UTRN generation, SMETS1 DCC user interface, request management and hosting, new security controls). For these services commercial delivery confidence is high. However where particular options offer a choice on the use or otherwise of existing services (for example integration path 4 versus integration path 5), then DCC s view of commercial delivery confidence varies on a cohort by cohort basis. Different approaches might potentially be adopted by different incumbent service providers, which could make the commercial delivery of a particular integration path challenging in certain situations. At this stage DCC therefore considers that limiting DCC to a solution that purely relies on either integration path 4 or 5 would lead to a low delivery confidence. However DCC is IEPFR Consultation DCC Public Page 83 of 144

84 confident that there is at least one way to create commercial arrangements for every cohort which means that overall commercial delivery confidence is high. The consequences of this are explored in section 7 on Implementation. 6.8 Consultation Questions Consultation Questions: Commercial 35 Are there any other commercial considerations that you consider that DCC should be taking into account? Please provide a rationale for your views. 36 Based on the information contained in the report, do you think that DCC s assessment of its commercial strategy is correct? Please provide a rationale for your views. IEPFR Consultation DCC Public Page 84 of 144

85 7 Implementation 7.1 Introduction The draft report has so far assessed the feasibility of various technical options for the provision of a SMETS1 Service by DCC. It has also considered commercial factors, including how they may affect the procurement of various elements of the SMETS1 Service and how commercial considerations may, in certain circumstances, influence the choice of technical option. The purpose of this section is to consider how, given the technical and commercial understanding gained thus far, DCC might approach the implementation of the SMETS1 Service, and to compare the relative merits of different implementation approaches. In forming a view on the preferred implementation approach, DCC considers that the focus should be on an approach that not only maximises the delivery of overall benefits, but one that provides flexibility of choice of integration approach and timing. There are many variables to consider in implementing a DCC SMETS1 Service and these will be explored and confirmed in the next phase of the programme. However, in order to demonstrate possible implementation approaches, DCC has developed a range of implementation options focussing on integration paths (i.e. integrate to SMSO or integrate to meter ). This approach provides the best insight into the possible implementation approaches given that, in order to maximise benefits, it is likely that difference implementation strategies (based on integration paths) will need to be applied on a cohort by cohort basis. Other areas of optionality identified in this report (e.g. UTRN generation) are not believed to have a material impact on delivery timescales or confidence or do not vary depending upon the implementation options selected (e.g. user interface). In line with this approach, DCC has developed three implementation options. The first two options consider two possible implementation solutions by either adopting integration path 4. integrate to SMSO for all meter cohorts or integration path 5 integrate to meter for all meter cohorts. The third hybrid option seeks to optimise the implementation approach by adopting specific integration path strategies on a cohort by cohort basis. DCC believes this option achieves the overall objectives of maximising early benefits whilst preserving flexibility and choice of integration path. It should be noted that the timescales presented in this section are estimates only at this stage and, as such, windows of delivery rather than firm delivery dates have been provided. These estimates will be refined into robust implementation plans at the appropriate stage of this project. The criteria used to evaluate these options are a subset of the criteria described in Appendix C and are described below: Timing the elapsed time to launch a DCC SMETS1 Service (Initial Operating Capability - IOC) and to complete that service for all meter cohorts (Final Operating Capability - FOC); Functionality the range of communications services supported; Cost - considered for both service build and service operation through life; and IEPFR Consultation DCC Public Page 85 of 144

86 Delivery Confidence a subjective assessment of the risk associated with technical delivery and commercial delivery. 7.2 Components of the Infrastructure To support the comparison of the three implementation options, an abstract architecture has been adopted. This is comprised of the elements described below: User Interface and Request Management DCC SMSO Interface plus SMSO system changes Translation and Comms Manager Describes the following components of a SMETS1 data service: the SMETS1 DCC user Interface together with any functionality required to allow the interface to exchange messages (e.g. request management) with other parts of the SMETS1 data services infrastructure (be that the SMSO interface function (under integration path 5) or the translation function (under integration path 4)). Describes the following components of a SMETS1 data service that would be required under integration path 5, (but not under integration path 4): the functions required to enable DCC to integrate to SMSOs and pass messages across that integration interface. It is assumed for the purposes of the analysis in this section that SMSO integration requires no further SMETS1 CSP integration and that the SMSO is already technically integrated with the SMETS1 CSP, and changes to SMSO systems are required either due to functional enhancements security enhancements or both. Describes the following components of a SMETS 1 data service under integration path 4 (but not under integration path 5): the functions that would integrate to the meter, including translation to meter protocols and integration to SMETS1 CSPs. Table 14 Components of the Infrastructure These elements will be seen in the plans for each of the implementation options to which they apply. 7.3 Enabling consistent assessment of timescales To enable a preliminary timescale assessment to be made in a consistent way and to allow the comparison of the implementation options, DCC has described components of a delivery plan. These components are described below. High Level Design High Level Design (HLD) is the term used in this section to denote the activities necessary to describe the defining of business requirements and developing the target architecture for a DCC SMETS1 Service. This includes developing requirements and analysis sufficient to support the initial procurement activity. IEPFR Consultation DCC Public Page 86 of 144

87 Procurement Commercial As used in this section, procurement means the activities required to contract for the SMETS1 data services that DCC will secure through competitive tendering processes (as described in section 6 Commercial). This refers to any activities required to re-negotiate existing arrangements with SMETS1 data and/or communications service providers, as opposed to procuring new services. Examples of this could include adoption of existing communications contracts and novation of existing SMSO services. Design, Build, Test Implementation Milestones This refers to the detailed design, development and testing of services required to support the provision of a DCC SMETS1 Service. In assessing the timetables, DCC has considered how to maximise benefit delivery over time and so have introduced two milestones: Initial Operational Capability (IOC) Window Initial Operational Capability is the window of time during which DCC expect to be able to offer a SMETS1 Service in respect of one or more cohorts of SMETS1 meters. Final Operational Capability (FOC) Final Operational Capability is the point at which it is currently anticipated that the DCC SMETS1 Service would be available in relation to all cohorts of meters within scope. Both IOC and FOC refer to DCC making available a service not the enrolment of meters. 7.4 Implementation Option 1 A key underpinning assumption for this option is that DCC seeks to integrate with SMSOs (integration path 5). The activities therefore focus on the creation of the new DCC data services that are competitively procured in the User Interface and Request Management workstream and multiple instances of a DCC SMSO interface in the DCC SMSO Interface workstream. IEPFR Consultation DCC Public Page 87 of 144

88 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 IEPFR consultation IOC Window Further Build/Migrate UI and Request Management High Level Design Procure Capability Iterative Design/Build/Test FOC DCC-SMSO interface plus SMSO system changes High Level Design Commercial negotiation with multiple SMSOs SMSO build activity Procure DCC-SMSO interface Iterative Design/Build/Test of DCC-SMSO interface First SMSO Go Live Further SMSOs go live Figure 16 Option 1 Integrate to SMSO In summary, the plan sets out: the new DCC Integration services are procured throughout 2017, with design, build and test completing at the end of Q2 2018; in parallel, commercial arrangements and negotiations progress with each SMSO; and the IOC window when the service is available for at least one cohort of meters is Q2 to Q Further SMSO s are then incorporated until the service is available for all cohorts by Q This option minimises the technical and integration challenges by using existing infrastructure, but would require upgrade work to SMSO services to enhance security. As a result, it has a medium technical delivery confidence. It has high commercial delivery confidence in relation to some cohorts, however it has lower commercial confidence if applied in relation to other cohorts, as DCC s current analysis suggests that this solution may not be capable of being secured commercially for all cohorts. This option requires the construction of separate SMSO integration solutions. DCC believes that this option can be delivered relatively quickly for those cohorts where it is commercially viable (faster than Option 2 but slower than Option 3) but is the highest through life cost option (as set out in section 8 costs and charging). In developing a plan for Implementation Option 1, it has been acknowledged that SMSOs are at different levels of development and each SMSO must be treated as a bespoke integration with differing potential requirements for security and (depending upon the IEPFR Consultation DCC Public Page 88 of 144

89 Communications Services Option chosen) possibly requirements for functionality development prior to integration. These requirements would be defined as part of the integration roadmap for that SMSO. Once the initial SMSO integration capability had gone live, further SMSO cohorts would go live over time. 7.5 Implementation Option 2 A key underpinning assumption for this option is that DCC seeks to integrate directly to meters (integration path 4) through a competitively procured new SMETS1 Service and through SMETS1 CSPs. The activities therefore focus on the creation of the DCC user interface and request management and the DCC translation and communications manager functions Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 IEPFR consultation IOC Window Further Build/Migrate FOC UI and Request Management High Level Design Procure Capability Iterative Design/Build/Test FOC DCC Translation and Comms Manager High Level Design Procure DCC Capability and negotiate with multiple S1 CSPs Iterative Design/Build/Test First Cohort Go Live Further cohorts go live In summary, the plan sets out: Figure 17 Option 2 Integrate to Meter the new user interface and request management capabilities are procured in 2017, with design, build and test completing at the end of Q2 2018; in parallel, there are a variety of activities to enable integration with the SMETS1 CSPs; and the IOC window when the service is available for at least one cohort of meters is Q2 to Q Further cohorts are then incorporated until the service is available for all possible cohorts by Q IEPFR Consultation DCC Public Page 89 of 144

90 As set out in section 8, this option is expected to cost less than Option 1 given the nonreliance on SMSO services and given that security enhancements and functionality could be built into the design of the service once. However, as set out in section 6, whilst there is high delivery confidence for this solution in relation to some cohorts, there is a low commercial delivery confidence for some based on intelligence that DCC has gathered to date. In developing a plan for Implementation Option 2, the following planning assumptions have been used: where the Adoption of Communications Contracts requires contracting with the incumbent SMSO, negotiation may be complex as set out in section 6; Communications Service option 1 would be selected where all of the minimum SMETS1 Services are provided on day 1. As set out in section 4.3, DCC only considers other Communications Services options to be plausible where you integrate to the SMSO (integration path 5); DCC envisages that the newly procured DCC Integration service will incorporate all of the security controls outlined in section 4 - Security at go live; and it will be necessary to engage SMETS1 CSPs and build interfaces between the new SMETS1 data services provider system and SMETS1 CSP systems. 7.6 Implementation Option 3 As set out in section 3 and confirmed above, DCC believes that either Option 1 or 2 are technically feasible. However, as set out in section 6, in some cases only one integration option may be viable for a particular cohort for commercial reasons. As such, the hybrid Option 3 seeks to exploit the benefits of Options 1 and 2 by providing an implementation approach that delivers the early benefits whilst retaining the flexibility of choice of implementation specific to a cohort. Additionally, Option 3 also de-risks delivery of the new DCC SMETS1 data services by providing options for early enrolment via the integration of SMSOs. A key underpinning assumption for this option is that DCC seeks to provide a SMETS1 Service as quickly as possible through a blend of integration to SMSOs and integration to meters directly. Each cohort will be assessed for the quickest integration path and planned accordingly. IEPFR Consultation DCC Public Page 90 of 144

91 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 IEPFR consultation IOC Window Further Build/ Migrate FOC UI and Request Management High Level Design Procure Capability Iterative Design/Build/Test DCC-SMSO interface plus SMSO system changes High Level Design Commercial negotiation with multiple SMSOs SMSO build activity Procure DCC-SMSO interface Iterative Design/Build/Test of DCC-SMSO interface First SMSO Go Live Further SMSOs go live DCC Translation and Comms Manager High Level Design Procure DCC Capability and negotiate with multiple S1 CSPs Iterative Design/Build/Test First Cohort Go Live Further cohorts go live Figure 18 Option 3 Hybrid In summary, the plan sets out: the new DCC user interface and request management capabilities are procured throughout 2017, with design, build and test completing at the end of Q2 2018; and meter cohorts are then implemented via one of the paths below: commercial arrangements and negotiations progress with each SMSO to deliver integration to SMSOs. The IOC window when the service (via SMSO) is available for at least one cohort of meters is between Q2-Q with the indicative date being Q Further SMSO s could then be added over time as required; and there are a variety of activities to enable integration to the meter. The IOC window when the service is available for at least one cohort of meters is between Q2-Q4 IEPFR Consultation DCC Public Page 91 of 144

92 2018, with the indicative date being Q Further cohorts are then incorporated over time. a service will be available to all meter cohorts by Q Key to this option is that it provides a phased approach designed to deliver early benefits and provide future commercial flexibility. Implementation option 3 has the fastest timeline to reach FOC, expected in Q It also addresses potential commercial constraints around certain cohorts not being able to be included in either Option 1 or Option 2. Option 3 provides for flexibility to deal with each cohorts needs individually and flex this over time if required. In order to optimise the speed, security and cost of a SMETS1 Service, DCC expects to support both integration paths. DCC would provide integration direct to SMSO (integration path 5) and in parallel would provide integration direct to meter (integration path 4). This approach allows bespoke solutions to be developed specific to each cohort, taking into account commercial enabler/constraints and technical integration and security challenges. The aim is to provide the fastest enrolment for SMETS1 meters at a reasonable cost. It is understood that SMETS1 market participants are considering ways to effect at least partial interoperability for certain cohorts of meters. DCC will consider, in the next phase of analysis, whether Option 3 can be accelerated by integrating to this market led solution, and what the impacts of doing so would be from a commercial and technical perspective. 7.7 Comparison of Options The table below provides a comparison of the options: Option 1 Option 2 Option 3 Timing Time to IOC is similar for Option 1 as it is for Option 3, given both have the potential for early SMSO integration. The FOC for Option 1, however, is expected to be the longest given the requirement for multiple instances of SMSO integrations. IOC: Faster FOC: Slower Time to IOC is expected to be the longest due to the requirement to procure and deliver a DCC SMETS1 service provider with greater functionality than under option 1. Time to FOC will be dependent on the extent to which services can be migrated across and the complexity of unravelling existing commercial relationships. As a result, time to FOC is expected to be longer than Option 3. Option 3 provides the best combination of quickest to IOC and FOC given the flexible implementation approach adopted. IOC: Faster FOC: Faster IOC Slower FOC: Faster than Option 1 and slower than Option 3 IEPFR Consultation DCC Public Page 92 of 144

93 Option 1 Option 2 Option 3 Functionality There are 3 communication service options in integrating to SMSO and a choice would need to be made on which option is preferable. It is likely that starting with the as is functionality would result in an earlier IOC but this would need to be confirmed as part of the stage of work. Integrate to meter has only one functionality option (all 37 services). Option 3 provides flexibility to make the optimal decision about functionality at the cohort level on integration. In instances where the integrate to SMSO is chosen, the functionality comments against Option 1 apply. Cost This option features the most supply chain layers which leads to the higher lifetime cost of service as all supply chain partners will incur costs that must be recovered. Thus Option 1 is expected to have the higher cost. Cost: High As Option 2 describes a supply chain with no SMSOs, it minimises the supply chain participants and therefore minimises the lifetime cost of a DCC SMETS1 Service. Cost: Low Option 3 provides flexibility to make cohort level optimisations across a range of criteria. Given that it may include the retention of one or more SMSOs, it has the medium lifetime cost. Cost: Low/Medium Delivery Confidence Due to commercial constraints, DCC does not expect to integrate to all SMSOs. Option 1 therefore holds low commercial confidence. Option 1 holds high technical delivery confidence. Overall delivery confidence: Medium: Due to commercial constraints, DCC does not expect to integrate all meter cohorts directly. Thus Option 2 therefore has the low commercial delivery confidence. However technical delivery confidence is high. Overall delivery confidence: Medium Option 3 has the highest delivery confidence. This is based on the ability to optimise both technical and commercial solutions for each cohort. Overall delivery confidence: High 7.8 End State Vision Whilst Option 3 has clear advantages over Options 1 and 2, prioritising the speed of enrolment may lead to transitional steps. Option 3 allows all cohorts to be enrolled quickly, following which, DCC may take further steps to achieve the enduring end state vision for the integration path represented by integration path 4 ( direct to meters ). DCC will develop the strategy to achieve the end state in the next phase of work, engaging industry on key steps and associated timescales as appropriate. 7.9 Conclusions The key findings for this Implementation section are: IEPFR Consultation DCC Public Page 93 of 144

94 implementation Options 1 and 2 have respective benefits (timescales vs lifetime costs) however Option 3 offers implementation flexibility and accelerates the flow of benefits from SMETS1 enrolment with DCC. Such benefits are not only timescale related but are `also related to achieving value for money. From the analysis carried out thus far Option 3 would maximise benefits over time and provide greater flexibility in delivery; as the existing arrangements differ for each cohort of meters, the timescales for delivering a SMETS1 Service differ by cohort. Some SMSOs and some direct cohorts could be enrolled quickly, others may take significantly longer; each cohort must be addressed with an individual implementation plan to maximise the delivery of benefits over time; DCC has an emerging view of how this could work for each cohort. This information cannot be shared due to commercial sensitivity but will be provided to BEIS to inform decisions; and where the quickest delivery route is not also the optimal enduring scenario, DCC can integrate and then seek to modify commercial and technical arrangements to create the optimal enduring solution for the life of the SMETS1 Service Consultation Questions Consultation Questions: Implementation 37 Do you agree that the implementation options presented provide an appropriate view of the ways in which the DCC SMETS1 Service could be implemented, or are there other implementation approaches that you believe would be more effective and efficient? Please provide a rationale for your views. 38 Do you agree with the assessment of each implementation option and the relative benefits of the hybrid Option 3? Are there other criteria that should be considered or criteria that should not? Please provide a rationale for your views. 39 What do you consider to be the risks, or other factors, in planning enrolment of meters into the DCC SMETS1 Service that need to be considered as part of implementation? IEPFR Consultation DCC Public Page 94 of 144

95 8 Costs and Charges In this section DCC provide an overview of DCC s approach and results to the cost modelling that underpins some of the analysis set out in the IEPFR. Given the sensitivity of cost data, DCC has not provided the cost model although this has been shared with BEIS. DCC has included in this section some relative and extract cost data to allow for differentiation between options. 8.1 Background The requirements for the IEPFR set out in section N of the SEC results in the following modelling requirements for DCC: SEC N4.1 requires DCC to provide an estimate for the overall cost of delivery of the enrolment of SMETS1 meters for each option set out in the IEPFR; and SEC N4.4 (m) requires DCC to set out an estimate of the premium payable in relation to communications contracts (where the costs exceed the costs of SMETS2) by the installing supplier as per the Second Relevant Charging Objective in DCC Licence. The cost model also identifies the variation in costs that occur if different technical and security options (as outlined in section 3 and 4) are chosen. 8.2 Core cost elements DCC is required to provide a cost analysis for all of the feasible options discussed in this document. The scope of this analysis is to estimate the direct costs that would be incurred by DCC as a result of providing a SMETS1 Service and, as such, costs incurred by other parties (e.g. energy suppliers in relation to changes within their own organisations) are excluded. At the highest level, the conceptual model used for the estimate of cost is based on two distinct phases over the lifetime of SMETS1 meters, each with an appropriate uplift for Optimism Bias an extra element applied to reflect current levels of uncertainty within cost estimates. The two phases are development and operation: For the development phase, fixed costs are estimated for each of the options as described in sections 3 and 4 which covers any new systems/it infrastructure required as well as changes to SMSO systems, SMETS1 CSP systems and the systems of existing DCC service providers. These costs to DCC comprise: Pre-build requirements such as feasibility assessment, procurement and high level design; and Build costs including detailed system design, build and test. Following the implementation phase, operational costs comprise: Service delivery comprising SMSO costs if integration path option 5 ( integrate to SMSO ) is chosen for any cohort, communications provider costs, application management support (for new elements of DCC data systems) and service management; and IEPFR Consultation DCC Public Page 95 of 144

96 System closedown (as all of the SMETS1 meters eventually are replaced). Figure 19 shows the high level conceptual framework used during the build of the Feasibility Cost and Charging Model (FCCM) described further below. Whole life cost of SMETS 1 meter enrolment Pre build costs Build Costs Service delivery costs Closedown costs Feasibility DCC project management DCC service management Closedown support Code amendments New build costs by build element Application management Procurement Existing system changes SMSO High level design Testing Communications Base costs Base costs Base costs Base costs Technical option costs Technical option costs Technical option costs Technical option costs 8.3 Model Implementation Figure 19 High level conceptual framework of the FCCM DCC has created the FCCM (the model ) to estimate and collate the costs that DCC is predicted to incur throughout development and operation of a SMETS1 Service. The FCCM also models how these costs might be passed on to SEC parties via the charging regime. The actual costs will, amongst other things, be dependent upon the decisions made concerning the technical, commercial and implementation strategies employed for the provision of a SMETS1 Service. The model is capable of providing DCC with analysis of the variability in cost type and the costs that DCC will incur in different options and timescales that may be selected. Development of the model has been assured by a suitably qualified external advisor with specific focus on the structure, design, logic and assumptions/input data that drive the model. 8.4 Key Assumptions There are a number of key input assumptions that materially drive the costs within the model. These key assumptions are summarised in the table 15 below and explored further in the subsections below. IEPFR Consultation DCC Public Page 96 of 144

97 Heading Value Considerations Number of Meters Life of meter Build On-going maintenance of the software application Cost of SMSO Cost of communications Optimism bias 10.22m across 6m households 15 years 1% p.a. failure rate. Varies by option Varies by option Varies by cohort Varies by cohort Variable by cost element Compiled from the energy suppliers responses to DCC s Commercial Clarification Questionnaires. Drives costs of communications services. Used as a base for the Charging Methodology. Scenarios covering different meter numbers will be modelled using sensitivity analysis. Life of a meter and failure rates have been derived from dialogue with individual energy suppliers about the expected life of a SMETS1 meter. This, together with the installation profile of meters and age of those meters on enrolment, drives the maximum length of time that the SMETS1 Service will be required and hence costs arising from that service. Derived from industry benchmarking and the experience of DCC s enrolment and adoption project team. Verified as being within the expected range by the external advisor. Derived from industry benchmarking and the experience of DCC s enrolment and adoption project team. Verified as being within the expected range by the external advisor. Compiled through dialogue with suppliers. Drives costs of potential SMSO contracts. Compiled through dialogue with suppliers. Drives costs of potentially adopted or new contracts. Compiled by service type. Assessed in accordance with HMT Green Book guidance Meter Numbers Table 15 Key input assumptions DCC s modelling relies on meter number submissions made by suppliers. Suppliers provided their forecast of Eligible Meters that will be installed by them in their original response to DCC s request for invitation. These forecasts were provided as a quarterly, cumulative volume of meters for each separate meter type. The number of households is also an important input assumption as the operational SMSO costs, communications costs and DCC s service management costs are calculated proportionally based on this IEPFR Consultation DCC Public Page 97 of 144

98 number. Based on the information provided by suppliers, DCC has used the number of eligible electricity smart meters as a proxy for the number of households as DCC understand that each SMETS1 communications module is reliant on an electricity smart meter being installed in order to provide power to the communications module. In total, thirteen suppliers have provided data and DCC intend to update these forecasts on a regular basis. In aggregate, suppliers have forecast that they will install 10.2 million Eligible Meters by the SMETS1 end date as per Figure 20 below. This comprises 6.0 million eligible electricity meters and 4.2 million gas meters. The model will use sensitivity analysis to explore scenarios where materially greater or materially fewer meters may be installed Life of meter A 15 year asset life and a device failure rate of around 1% p.a. over the appraisal period is assumed based on information provided by suppliers. There is a further assumption that any failure results in replacement with SMETS2 meter. Suppliers have also provided DCC with a profile of meter installations which began in At the point of enrolment, therefore, many of these meters will have been installed for a number of years. DCC has taken this into account when modelling the remaining life of meters, so some meters will come to the end of their life well before enrolment plus 15 years. The 1% failure rate (supplier s expected smart device failure rates) provides for a slight contraction of the SMETS1 meter population over time with a steeper decay from 2031 onwards. In this context, it is important to note that DCC s cost estimate reduces as a result of each SMETS1 failure as the incremental cost of communicating with the SMETS1 meter via the SMETS1 CSP (and where relevant the SMSO) is no longer incurred. Furthermore, a supplier s cost of installing a SMETS2 meter to replace a failed SMETS1 meter is outside the scope of DCC s analysis Build Costs DCC s assessment of build costs is based on a range of assumptions and reference classes and, at this point, there is limited evidence that can be used to validate them given that DCC are currently at the feasibility stage of the analysis. The large majority of the build is made up of core systems requirements, which include request management, translation, communication management, key management and other security processes. The cost of these core system build components has been calculated using estimates of development resource and equipment required, together with an assessment of day rate for the resources. The system requirements are typically independent of the number of meters enrolled. Some incremental build requirements are anticipated, and these depend upon the choices made in technical options. DCC has estimated the costs for these optional system build components in a similar manner to those for the core system components. The majority of build costs are fixed and independent of cohort sizes. This is because the system is being developed for a significant portfolio of meters and even with the removal of the largest cohorts of meters, the core requirements of the system remain the same. DCC do recognise that the component costs for each implementation approach set out in IEPFR Consultation DCC Public Page 98 of 144

99 Section 7 will be different, although this does not materially impact the overall whole life cost. DCC may also incur licensing costs for the inclusion of pre-existing software and hardware elements into DCC system. These costs will also occur on a component by component basis. Build cost New system build costs New system licensing costs Existing system adaptation costs Effort days per project block (1) Effort days per project block (n) Licensing fees (project block 1) Licensing fees (project block n) Effort days per project block (1) Effort days per project block (n) Blended daily rate per project block 1 Blended daily rate project block n Blended daily rate per project block 1 Blended daily rate project block n Costs due to technical options Costs due to technical options Costs due to technical options Costs due to technical options Costs due to technical options Costs due to technical options Indexation Discount rate New system build optimism bias Existing system adaptation optimism bias Figure 20 Build Cost Framework On-going support of the DCC system - Application Management Support The Application Management Support (AMS) costs cover the support costs for the SMETS1 related data systems. These are assumed to be an annual cost based on a percentage of the total development costs (excluding Optimism Bias and software licensing). Application management support ( AMS ) is assumed to be a fixed amount per annum determined as a proportion of the total developmental costs of the new system build and existing system adaptations. This proportion has been estimated to be 20% per annum. This method of calculating AMS costs is comparable to the maintenance fee of software licence arrangements. DCC has compared the whole life costs of AMS calculated using several methods, including a bottom up calculation of costs. These methods provide similar whole life costs for this proportion of the programme spend and DCC has therefore IEPFR Consultation DCC Public Page 99 of 144

100 selected the fixed amount per annum method because it is simpler to understand and model at this stage of the analysis Costs of SMSO and communications SMSO and communications costs are modelled to be on a per household basis aligned to the cost structures within existing service contracts. Charges paid to an SMSO and a SMETS1 CSP have been collated for each supplier. There are 13 energy suppliers and 6 SMSOs. In relation to SMSO and FCSP costs there are three distinct cost structures across the 16 distinct cohorts. For the purposes of this modelling exercise, DCC has defined a cohort as a group of meters operated by an individual energy supplier that have the same communications and SMSO providers under the same commercial terms. A summary of this view is provided below: 7 cohorts are charged on the basis of an annual bundled fee per household; 7 cohorts are charged on the basis of an annual fee per meter plus an annual (or monthly) SIM fee; and 2 cohorts are charged on the basis of a fixed monthly SMSO Fee + monthly fee per meter + annual service fees per household + monthly SIM Charge + excess fee for data above a threshold. DCC has normalised the cost data for these three groupings in a single cost structure for analysis with the following two drivers: SMSO fee per household; and SMETS1 CSP fee per household. Figures 22 and 23 show the way that the model calculates SMSO and SMETS1 CSP costs, respectively. IEPFR Consultation DCC Public Page 100 of 144

101 SMSO cost Cohort 1 SMSO costs Cohort 2 SMSO costs Cohort 3 SMSO costs Cohort n SMSO costs Rate per household (Cht 1) Rate per household (Cht 2) Rate per household (Cht 3) Rate per household (Cht n) Number of households (Cht 1) Number of households (Cht 2) Number of households (Cht 3) Number of households (Cht n) Indexation Discount rate Optimism bias Figure 21 SMSO Cost Calculation Methods IEPFR Consultation DCC Public Page 101 of 144

102 Communications cost Cohort 1 comms costs Cohort 2 comms costs Cohort 3 comms costs Cohort n comms costs Rate per household (Cht 1) Rate per household (Cht 2) Rate per household (Cht 3) Rate per household (Cht n) Data overage cost (Cht 1) Data overage cost (Cht 2) Data overage cost (Cht 3) Data overage cost (Cht n) Number of households (Cht 1) Number of households (Cht 2) Number of households (Cht 3) Number of households (Cht n) Indexation Discount rate Optimism bias Figure 22 SMETS1 CSP Cost Calculation Methods DCC has performed a data utilisation exercise to estimate the data requirements by meter for the DCC SMETS1 Service, allowing for day-to-day operation, periodic updates of firmware and interrogation of meters by other users such as switching sites. DCC envisage that some existing data contracts may not provide for sufficient data allowances to allow for the anticipated data usage for the full SMETS1 system. Where appropriate, DCC has included data overage costs for those meters. At this stage of modelling, DCC has used the current costs as the proxy for future costs Optimism Bias Given the current stage of development, there is a degree of uncertainty within the modelling assumptions. As a result DCC has applied Optimism Bias (OB) to costs within the FCCM. DCC has implemented an approach consistent with the Treasury s Green Book Guidance for OB. This approach starts with upper bound figures for elements of costs taken from the Green Book Guidance which is based on other similar projects and reflective of the current stage of the overall programme. These upper bound figures are then reduced where DCC has identified a mitigation factor and thus there is greater certainty (e.g. there are existing contracts in place for changes to the DSP). IEPFR Consultation DCC Public Page 102 of 144

103 The outcome of this approach is that differing values of OB are utilised in the FCCM for the following three cost areas: new system build - New SMETS1 Data Services Provider & SMSO Build - The upper bound figure is 200% and adjusted to 64% based on mitigation factors; amendment of existing DCC systems SMETS2 DSP Build - The upper bound figure is 200% adjusted to 51% based on mitigation factors; on-going operational costs (apart from SMSO and SMETS1 CSP) - The upper bound figure is 41% adjusted to 21% based on mitigation factors; and the estimates of optimism bias will be reduced in the future due to increased amounts of knowledge concerning design of all aspects of the programme. 8.5 Indexation and Discounting DCC has presented costs on a comparable basis to the smart meters Impact Assessment to put them in the context of the wider costs of the smart meter rollout. All costs have been expressed in real terms in 2011 prices and discounted to 2016 using a social discount rate of 3.5%. This is in line with guidance published in the HMT Green Book. 8.6 Outputs for the IEPFR Base costs We have determined, should the Secretary of State instruct us to build a solution, that DCC will incur costs for several components of the programme that are common to all technical options. These common costs comprise costs for system design, build, test and operational support and service management. The total whole life cost of this is in the range of 150m to 185m Comparison of costs We have compared the costs of the three options in the implementation section. The key decisions that drive whole life cost are those concerning the implementation path taken for each cohort of meters. As set out in section 7, the analysis of the implementation options confirms that option 2 has the lowest whole life cost. The whole life cost of implementation option 3 is higher than that of option 2. Option 1 has the highest whole life costs. Furthermore, DCC s analysis is purely cost based and so does not account for the benefits of proceeding with an enrolment project e.g. Interoperability (retention of smart functionality on churn) and access to data / functions for other users. DCC has also evaluated the costs of the technical and security options. Tables 16 to 20 outline the results of this analysis. This analysis shows the relative, incremental (above the base costs), qualitative cost for each option together with a description of the significance of each option to the overall whole life cost. IEPFR Consultation DCC Public Page 103 of 144

104 Integration Path Option 4 ( integrate to meter ) Integration Path Option 5A ( integrate to SMSO ) Integration Path Option 5B ( integrate to SMSO ) Enrolment Service Costs Lower Higher Higher Costs are estimated to range between 130m - 420m. The above costs include costs for communications, SMSOs and integration option specific build and application support. It should be noted that the costs of the Integration Path Options are a combination of new costs and existing costs that are already being incurred by Energy Suppliers. Under Adoption and Enrolment, these existing costs would then be borne by the DCC, specifically costs incurred under SMSO (if integration path 5 is chosen) and SMETS1 CSP contracts. DCC expects that where translation is developed centrally (Option 5a) that whole life enrolment service costs could be marginally lower than where multiple industry providers develop translation. The impact of this will be quantified through the design phase of the programme. Table 16 Comparison of the Cost of Technical Options Integration Path SMETS1 DCC User Interface Option 1 SMETS1 DCC User Interface Option 2 SMETS1 DCC User Interface Option 3 Enrolment Service Costs Lowest Higher than option 1 but lower than option 3. Highest Costs are estimated to range between 10m - 120m. The cost for user interface technical options is dependent upon the level of development effort required for each option. Table 17 Comparison of the Cost of Technical Options User Interface Communication Services Option 1 (minimum 37) Communication Services Option 5 (asis) Communication Services Option 6 (as-is moving to minimum 37) Enrolment Service Costs Higher than option 5 but lower than option 6 Lowest Highest Costs are estimated to range between 0m - 20m The costs of the communications services technical options are dependent upon the level of effort required to deliver the required number of services within the build. Table 18 Comparison of the Cost of Technical Options Comms Services IEPFR Consultation DCC Public Page 104 of 144

105 UTRN Option 1 UTRN Option 2 UTRN Option 3 Enrolment Service Costs Similar to other UTRN generation options Similar to other UTRN generation options Costs are estimated be approximately 10m. Similar to other UTRN generation options Table 19 Comparison of the Cost of Technical Options Pre Payment Criterion CSP Limitations System Hardening Islanding Enhanced Key Management Enrolment Service Costs Costs are estimated to range between 5m - 35m 8.7 Sensitivities Table 20 Comparison of the Cost of Security Options The whole life cost of DCC enrolment of SMETS1 meters is heavily influenced by the options that are selected in the specification of the future service. Of this potential set of technical and security options, the most significant driver is the integration path chosen, as seen above. Other options, such as choice of user interface have a lesser effect upon the whole life cost. The selection of particular technical and security options is not the only influence on whole life cost of provision. DCC has found that it is sensitive to variability in several factors. The most significant of these are meter numbers, on-going SMSO and communications contract costs, build and AMS cost, and optimism bias. Broadly speaking, an increase (or decrease) of any of the above factors will cause an increase (or decrease) in the whole life cost of the enrolment of SMETS1 meters. Earlier enrolment of meters will increase DCC costs, and will accelerate the benefits associated with DCC enrolment of meters. 8.8 Charging Premium DCC levies charges for its service in accordance with the Charging Methodology for service charges, as defined in section K of the SEC. This methodology currently provides for the recovery of the majority of DCC s costs via a monthly per meter charge across specified charging groups. It was always expected that the existing Charging Methodology of the SEC would be changed to account for DCC enrolment of SMETS1 meters. These changes will be governed by provisions already present in the DCC Licence. Changes to the existing Charging Methodology to reflect SMETS1 costs would have to be structured in a way that complies with the Charging Objectives in the DCC Licence. Those objectives apply equally for SMETS1 and SMETS2 service charges, with the exception of the Second Relevant Policy Objective (clause 18.16). This Second Objective states that any excess communications costs arising from adopted communications contracts (when compared to SMETS2 communications costs) should be paid directly by the supplier who entered into the original communications contract, until such time as that supplier s SMETS1 customer churns. Consistent with the Charging Objectives, all other SMETS1 costs would be included with DCC s overall costs and spread across all enrolled smart meters (i.e. SMETS1 and SMETS2) via the monthly per meter charge across the charging IEPFR Consultation DCC Public Page 105 of 144

106 groups. Should DCC proceed with SMETS1 Service provision then the section K Charging Methodology would need to be amended (alongside the other SEC changes that deliver SMETS1 service provision) to reflect the second charging objective. The communication services for SMETS2 are of a different standard (in terms of both technical and performance standards) to those for SMETS1. Consequently if taken at face value and as is to be expected, DCC s initial analysis indicates that the communications costs for SMETS 2 are higher than those for SMETS 1, where an unbundled communications cost is identifiable. In this case, no premium for the excess costs would be charged to any supplier using a SMETS1 meter. However DCC is required, as a result of the charging objective, to compare the services on a like for like basis. SMETS2 CSP contracts include the provision of many different services at high coverage levels. These obligations have led to the provision of infill mesh technology in the case of the Southern and Central contracts, and a completely new radio network for the Northern contract. The SMETS2 CSP contracts are essentially fixed price agreements in which DCC s service partners commit to providing the communications services against high levels of coverage, against a wide range of predicted data usage and against a strict set of service level requirements. DCC s analysis of existing communications arrangements that have been procured for SMETS1 reveals that they are predominantly price per SIM card arrangements. Some of them have service level arrangements; others do not. The CSPs costs for the provision of the SMETS2 services are not unbundled to provide a simple communication cost that is directly comparable to those that might be incurred for the SMETS1 Service and thus the comparison requires DCC to make a range of unbundling assumptions in order that DCC can compare like for like costs. Furthermore, the expectation of utilisation of any SMETS1 Service once within DCC s infrastructure is at present uncertain, making the calculation of costs that might be incurred under that contract more difficult (due to, for example the possible incurrence of overage charges). At the present time, the initial basic comparisons of communication costs between SMETS1 and SMETS2, suggest that there will not be an excess charge for any SMETS1 communications. However, if the project proceeds, further details of the utilisation for SMETS1 related services will become apparent and then there would be merit in investigating the unbundling of the CSPs cost to allow a further assessment of the premium. 8.9 Summary DCC has found that the key decisions that drive whole life cost are those concerning the integration path taken for each cohort of meter. Key cost drivers comprise: number of meters enrolled (adjusted for assumed failure rates); cost of system build and on-going application management and support; cost of adopted / re-contracted SMSO agreements; cost of adopted / re-contracted communication agreements; and optimism bias. IEPFR Consultation DCC Public Page 106 of 144

107 At this point DCC considers that the costs of SMETS1 and SMETS2 communications are unsuitable for direct like for like comparison, hence the calculation of excess costs of communication for direct charge to individual suppliers would be speculative. Consequently this matter requires further analysis and investigation Consultation Questions Consultation Questions: Commercial 40 Do you agree with the approach that DCC has adopted to the modelling of IEPFR costs, or should any amendments be considered? Do you agree with DCC s key input assumptions on costs, or should any amendments be considered? 41 Are there other key sensitivities that you consider should be modelled at this stage and if so, what are they? 42 Do any of the options outlined in this report result in materially different costs to your organisation (based on your estimate)? Please provide details. 43 Do you agree with the early view on the Second Relevant Policy Objective regarding the charging for excess SMETS1 communications costs? If you disagree, what other factors should DCC consider? IEPFR Consultation DCC Public Page 107 of 144

108 9 SMETS1 Services under the SEC In this section, DCC provide a high level analysis of the types of changes that might be required in the SEC to support the provision by DCC of a SMETS1 Service and any gaps or inconsistencies that need to be explored further. The analysis undertaken during this feasibility stage is not intended to produce an exhaustive list of potential Initial Enrolment Code Amendments (IECAs). 9.1 Enrolment process SMETS1 Device Models that can be enrolled with DCC All of the Device Models that are included within the scope of this draft report are potentially eligible for SMETS1 enrolment. DCC has identified the following areas where code amendments may be needed in order to provide the necessary rights to support enrolment: status of meter communications prior to enrolment in order to support the enrolment process, in addition to having contracted for communications services, DCC will need to be capable of establishing communications with the SMETS1 meter. This ability to establish communications will therefore need to be a pre-condition to a supplier s right to enrol; and entitlement to enrol SMETS1 electricity and gas and meters that share a single communications hub and are installed at dual fuel premises with separate electricity and gas suppliers the pre-conditions for enrolment of such meters and the rights and obligations on the relevant suppliers will require clarification Device Models outside of the scope of the Initial Enrolment Project Section N4.4 requires that DCC include within the IEPFR its analysis regarding: (g) to the extent that they (rights) can be offered without a material increase in cost, risk or timescale, any rights for Parties also to Enrol SMETS1 meters which were not included within the scope of the IEPFR; From a regulatory perspective, DCC has considered the following areas where the SEC will need to be amended: entitlement to additional quantities of Device Models that are of a type already accepted for inclusion in the scope of Initial Enrolment, but not included in the Initial Enrolment Project the SEC will need to set out any rights for enrolling additional quantities of these Device Models, and whether any limits are placed on the numbers of Devices being enrolled at any one time; and rights and obligations regarding enrolment of Device Models which were not included within the scope of the Initial Enrolment Project DCC does not anticipate that there will be an automatic right for these Device Models to be enrolled. There may be a material impact on cost or risk resulting from enrolment of a SMETS1 meter that is not of a type that was included in the scope of the IEPFR, given that the technical solution supporting that meter type might not be catered for. DCC considers that changes to the SEC to enable these Device Models to be enrolled must be accompanied by a IEPFR Consultation DCC Public Page 108 of 144

109 robust Impact Assessment at the point that enrolment is proposed. Therefore such changes would need to be progressed via a SEC modification. 9.2 Communication Services Service Requests and Responses The DCC User Interface Specification (DUIS) and the DUIS XML schema fully describe the structure, format and validation rules relating to Service Requests and Service Responses. The Message Mapping Catalogue (MMC) and MMC XML schema describes the Output Format of Device Responses and Device Alerts. Any changes to these documents, or the need for a new SMETS1 User Interface Specification will be determined by the combination of Communication Services and user interface options selected for the Initial Enrolment Project (summarised in sections 3.3 and 3.4). Target Response Times and Performance Standards The SEC sets out Target Response Times for various DCC activities relating to Service Requests, Responses and Alerts which are relevant to the SMETS2 solution and DCC s SMETS2 Service Providers contracted capabilities. Integration path Options 4 and 5 utilise some or all of the existing SMSO and SMETS1 CSP infrastructures to provide the SMETS1 Service and these may not provide performance related service levels that are equivalent to the Target Response Times in the SEC. Consideration will therefore be required of whether DCC can contract for performance standards with incumbent service providers that more closely approximate the SMETS2 standards, or whether SMETS1 Services will require alternative, or amended Target Response Times. In making such decision, the costs and benefits of the two approaches will need to be considered. 9.3 Process for enrolling SMETS1 Meters The SEC will need to include comparable requirements to those in place for current SMETS2 Services to support the enrolment of SMETS1 meters. These include communications services (and non-device requests) necessary to: add devices to the Smart Meter Inventory; activate SIM cards with SMETS1 CSPs; establish WAN communications with a communications hub; configure a communications hub; establish the HAN; whitelist HAN device on the communications hub; and send command to the communications hub to permit joining of HAN devices. IEPFR Consultation DCC Public Page 109 of 144

110 9.4 Becoming an eligible user for SMETS1 enrolment and communication services There may be a requirement for Parties who wish to become users of the SMETS1 Services to complete additional User Entry Process Tests in respect of the relevant user Roles for the SMETS1 service requests to the extent that they differ in format to SMETS2 service requests. Whether or not any additional security requirements need to be satisfied by the user will depend upon the security options chosen. 9.5 Security Depending on the security options selected, there may be SMETS1 specific security obligations that will need to be captured in the SEC, for example enhanced key management obligations which may need to be placed on DCC and users to ensure that the overall risk to the DCC Total System is not increased. 9.6 Communications Hub Services The Communications Hub Services defined in the sections F5-9 of the SEC are specific to the Communications Hubs supplied by DCC as part of the SMETS2 rollout. Communications hubs used with SMETS1 meters (usually part of the Electricity meter) are compatible only with specific meter types and are ordered direct from manufacturers and owned by suppliers or MAPs. Services concerned with the forecasting, ordering, delivery, installation, maintenance, removal and return of SMETS2 Communications Hubs are therefore not relevant to the DCC SMETS1 Service. However as set out in section 3.4.7, DCC may need to provide SIM cards upon request to suppliers. If this service is required, the SEC will need to be amended to accommodate this. 9.7 Other Enabling Services Enduring Testing Services Section H14 of the SEC sets out the Testing Services that DCC must provide in relation to SMETS2 Devices, which include user Entry Process Tests; SMKI and Repository Entry Process Tests; and Device and user System Tests. Comparable Testing Services will most likely be required for SMETS1 service users, so that they can demonstrate their ability to interface with DCC with regard to communications with Devices, and any supporting security infrastructure, plus a means for SMETS1 service users to test their own systems against DCC. DCC expects to consider the testing requirements in the SEC in further detail as part of the subsequent analysis of IECA when there is additional clarity regarding which technical and security options are selected Service Management Sections H8-10 of the SEC set out DCC's obligations in respect of provision of Service Management. As set out in section 6, a Service Management capability will be needed to support the DCC SMETS1 Service comprising similar components to those set out in the SEC for current DCC Services. These include: IEPFR Consultation DCC Public Page 110 of 144

111 Maintenance of the relevant DCC SMETS1 Systems; a Self-Service Interface; a Service Desk; Incident and Problem Management; and Business Continuity and Disaster Recovery. Service Management amendments will include changes to the Self Service Interface to reflect data and information specific to DCC enrolled SMETS1 meters Connecting to the DCC SMETS1 Service The SEC includes obligations regarding the provision and use of DCC Gateway Connections to connect to both DCC user interface and the self-service interface. Depending on which user interface option(s) are selected, the SEC may require additional provisions to set out the requirements relating to any new network connections and/or user interface services for the SMETS1 Service UTRN generation services As set out in section 3.5, DCC considers that it would need to provide a UTRN generation service to support the provision of an interoperable prepayment solution for DCC enrolled SMETS1 meters. Options for the form that service provision may take are set out in that section, and the SEC will need to be amended to define the rights and obligations relating to the generation of UTRNs. 9.8 Data Privacy Section I of the SEC contains obligations on DCC and Users in respect of Data Protection and Access to Data. Sections I1.6 and I1.7 acknowledges that DCC may act as a data processor on behalf of Users who are data controllers and describes the manner in which DCC will fulfil this role. DCC's analysis of the current SMETS1 solutions and the options for enrolment of SMETS1 meters has identified that DCC will also be required to act as in this role in respect of Personal Data received from DCC enrolled SMETS1 meters. DCC therefore does not anticipate requiring any amendments to section I of the SEC. 9.9 Charging for SMETS1 Services The SEC and DCC Licence contain clear requirements setting out how DCC recovers any costs that it incurs. These costs are recovered via a Fixed Charge, Explicit Charge and, under certain conditions for SMETS1 Services, a premium charge for adopted services. Section 8 of this document describes the charging arrangements for SMETS1 Services and section K of the SEC will need to be amended to deliver this charging methodology Material changes to Section M of the SEC Section M of the SEC sets out contractual arrangements relating to matters such as confidentiality, IPR, liabilities and dispute resolution. These provisions were drafted in IEPFR Consultation DCC Public Page 111 of 144

112 relation to SMETS2 Services. Section M was developed contemporaneously with the SMETS2 service provider contracts that were put in place to support the delivery of DCC SMETS2 services, and, whilst general in nature, are in some cases specific to those contractual arrangements that exist between DCC and its service providers. It is therefore possible that some of the contractual provisions in section M may need to be amended, depending upon the contractual arrangements put in place with SMETS1 Service providers. However this requires on-going consideration and will require further analysis as procurement of service provider capability to support SMETS1 Services progresses. IEPFR Consultation DCC Public Page 112 of 144

113 Appendix A Definitions & Acronyms Definitions Where capitalised terms are used in this draft report, which are not defined within this report, please refer to the SEC for the relevant definitions. Acronyms For ease of reference, the acronyms used in this report which are not defined terms are detailed below together, where applicable, with the documentary origin of the acronym. Acronym Expansion BEIS Department of Business, Energy and Industrial Strategy CCQ Commercial Clarification Questions CSP Communication Service Providers DCC Data and Communications Company DCCKI DCC Key Infrastructure DSP Data Service Provider DUIS DCC User Interface Specification EOT Enrolment Options Testing GIT GBCS Interface Testing GBCS Great Britain Companion Specification HAN Home Area Network HES Head End System HHT Hand Held Terminal IEPFR Initial Enrolment Project Feasibility Report IHD In Home Display IPR Intellectual Property Rights PAN Personal Area Network, Payment Authorisation Number or Prepayment Authorisation Number (depending on context) PKI Public Key Infrastructure PPMID Prepayment Interface Device RSC Relevant Service Capability SEC Smart Energy Code SIM Subscriber Identity Module or Subscriber Identification Module SMETS1 Smart Metering Equipment Technical Specification 1 SMETS2 Smart Metering Equipment Technical Specification 2 SMKI Smart Metering Key Infrastructure SMSO Smart Meter Systems Operator SSC Security Sub Committee UTRN Unique Transaction Reference Number XML Extensible Markup Language Zigbee A wireless communications protocol and standard IEPFR Consultation DCC Public Page 113 of 144

114 Appendix B Consultation Questions Consultation Question Integration Path options Q1 Q2 Q3 Q4 Do you agree with the range of integration path options that DCC has considered, or do you consider that there are other integration path options that should be considered? Please provide a rationale for your views. Do you agree that integration path options 1-3 should not be progressed on the grounds of cost and technical risk? Please provide a rationale for your views. Do you agree with the analysis of the relative advantage and disadvantages of integration path options 4 ( integrate to meter ) and 5 ( integrate to SMSO )? Please provide any other views on the relative advantages and disadvantages of integration path options 4 and 5. Please provide a rationale for your views. Please provide views on whether, were option 5 ( integrate to SMSO ) to be adopted, 5a or 5b is preferable. Please provide a rationale for your views. SMETS1 DCC user interface options Q5 Q6 Q7 Q8 Do you agree with the range of SMETS1 DCC user interface options that DCC has considered, or do you consider that there are other options that should be evaluated? Please provide a rationale for your views. Do you agree with the analysis of the relative advantage and disadvantages of each of the SMETS1 DCC user interface options? Please provide a rationale for your views. Please tell us which SMETS1 DCC user interface option you consider to be preferable. Please provide a rationale for your views. Please provide your views on whether either SMETS1 DCC user interface option 2 or 3 better facilitates achievement of the SEC Objectives than SMETS1 DCC user interface Option 1. Please provide a rationale for your views. Communications Service options Q9 Q10 Do you agree that the additional services that are currently provided by SMSOs that are not part of the Minimum 37 Services should be made available by DCC as elective communication services, should the supplier wish to continue to receive those services? Please provide a rationale for your views. Do you agree that communication services options 2, 3 and 4 should be discounted? IEPFR Consultation DCC Public Page 114 of 144

115 Consultation Question Please provide a rationale for your views. Q11 Q12 Q13 Q14 Q15 Q16 Q17 Q18 Do you agree with the evaluation of communication services options 1, 5 and 6 and do you consider that there are other advantages and disadvantages of any of those options that should be considered? Please provide a rationale for your views. Which communication services option do you consider is preferable? Please provide a rationale for your views. Do you agree that the two security-related service requests set out in Table 4 are not required for DCC enrolled SMETS1 meters? Please provide a rationale for your views. Do you agree that the Non-Device requests listed in Table 5 are required for DCC enrolled SMETS1 meters? Please provide a rationale for your views. Do you have a preference for the approach to implementing the Update Firmware Service for enrolled SMETS1 meters? Please provide a rationale for your views. Would you use DCC scheduled services if offered by DCC in respect of enrolled SMETS1 meters? Please provide a rationale for your views. Do you agree that DCC should provide a standardised set of service requests for commission and decommissioning SMETS1 devices that most closely approximates the process for SMETS2 devices? Please provide a rationale for your views. Do you anticipate ordering additional communications hubs from your existing vendor(s) during the life of DCC SMETS1 Service and, if so, would you require DCC to provide SIM cards? Please provide a rationale for your views. Prepayment options Q19 Q20 Q21 Q22 Do you agree with the options that DCC has identified for the provision of a UTRN generation service and are there others that should be considered? Please provide a rationale for your views. Do you agree with the assessment of the advantages and disadvantages of each UTRN generation option and are there others that should be considered? Please provide a rationale for your views. Which UTRN generation option do you consider to be preferable? Please provide a rationale for your views. Do you consider that payment service providers should become eligible to use the Top- Up Device services on a supplier s behalf? Please provide a rationale for your IEPFR Consultation DCC Public Page 115 of 144

116 Consultation Question views. Q23 Q24 Do you consider that a one-step or two-step process for sending an OTA Top up to a SMETS1 Meter is preferable? It would be useful to understand the advantages and disadvantages of each approach as you perceive them, including the relative efficiencies to a user of a single step process (which aligns with current SMETS1 processes and implies a single interface) versus a two-step process (which more closely aligns with SMETS2 processes and results in two interfaces)?please provide a rationale for your views. Do you agree that SMETS1 IHDs with PPMID-like functionality should be included in the Smart Metering Inventory as a separate device type to other IHDs? Please provide a rationale for your views. Security Q25 Q26 Q27 Q28 Do you agree with the approach set out in section that DCC has adopted for assessing a material increase in risk? Please provide a rationale for your views. Are there any security option areas or significant measures which have not been outlined in section that you would consider of key importance to a SMETS1 solution? Please provide a rationale for your views. Are there any additional security issues that would need to be taken into account when assessing the technical options described in section 4.2? Please provide a rationale for your views. Do you have any comments on the feasibility of implementing the identified security options? Please provide a rationale for your views. Service Delivery Q29 Q30 Q31 Q32 Do you agree that a single Service Desk and single Self Service Interface should be provided for SMETS1 and SMETS2? Please provide a rationale for your views. Do you agree that any new SMETS1 service providers should conform to the Service Management Standards? Please provide a rationale for your views. Do you agree that any new SMETS1 service provider should comply with the Initial Target Response Times and Target Resolution Times for Incidents required by the SEC? Please provide a rationale for your views. Do you agree that the same level of self-diagnosis tools should be provided to users IEPFR Consultation DCC Public Page 116 of 144

117 Consultation Question for SMETS1 as those for SMETS2? Please provide a rationale for your views. Q33 Q34 Do you agree with the proposed approach to Business Continuity and Disaster Recovery? Please provide a rationale for your views. Do you agree with the analysis of options for the Service Management System? Please provide a rationale for your views. Commercial Approach Q35 Q36 Are there any other commercial considerations that you consider that DCC should be taking into account? Please provide a rationale for your views. Based on the information contained in the report, do you think that DCC s assessment of its commercial strategy is correct? Please provide a rationale for your views. Implementation Q37 Q38 Q39 Do you agree that the implementation options presented provide an appropriate view of the ways in which DCC SMETS1 Service could be implemented, or are there other implementation approaches that you believe would be more effective and efficient? Please provide a rationale for your views. Do you agree with the assessment of each implementation option and the relative benefits of the hybrid Option 3? Are there other criteria that should be considered or criteria that should not? Please provide a rationale for your views. What do you consider to be the risks, or other factors, in planning enrolment of meters into the DCC SMETS1 Service that need to be considered as part of implementation? Costs and Charges Q40 Q41 Q42 Q43 Do you agree with the approach that DCC has adopted to the modelling of IEPFR costs, or should any amendments be considered? Do you agree with DCC s key input assumptions on costs, or should any amendments be considered? Are there other key sensitivities that you consider should be modelled at this stage and if so, what are they? Do any of the options outlined in this report result in materially different costs to your organisation (based on your estimate)? Please provide details. Do you agree with the early view on the Second Relevant Policy Objective regarding the charging for excess SMETS1 communications costs? If you disagree, what other IEPFR Consultation DCC Public Page 117 of 144

118 Consultation Question factors should DCC consider? IEPFR Consultation DCC Public Page 118 of 144

119 Appendix C Assessment Criteria The table below summarises the assessment criteria used to assess the options in this report: Criteria Description Potential Influence of Options Enrolment Service Costs Timing Delivery Confidence Functionality Impact on Users Security DCC SMETS1 costs are driven by a combination of the number of meters enrolled, the costs of providing the service and contract costs (including running costs of existing and new contracts, termination and novation). Timing of enrolment is influenced by the complexity of the solution in terms of: commercial arrangements design, build and test (including changes to supplier services) implementation Delivery confidence combines two aspects: Technical how complex the technology is, whether it has been used before, who is responsible for development and risk to implementation Commercial type and complexity of arrangements required to enable enrolment For this study, functionality is defined to include three aspects: Breadth of services supported (measured against minimum SMETS1 Services) Performance in terms of transaction times Performance in terms of availability and resilience Enrolment into DCC services may have a number of potential impacts on users including changes to: Contracts Business processes (may reuse SMETS2) Existing services from other service providers SMETS1 meters (e.g. change of communications hub) In the context of each option it must be considered whether there is a material increase in risk to: User Systems DCC Total System Enrolled Smart Metering Systems Options have a potentially significant effect on these costs by influencing the number and type of contracts required to enable enrolment and the number of SMETS1 meters that are capable of enrolment through a given option. Options may impact timing through the level of new development required by DCC or other parties (e.g. SMSOs) or number of contracts to adopt, change or procure. Options that require more development of bespoke technology or establishment of large numbers of commercial arrangements may have lower delivery confidence. A potential solution may support only a subset of the defined minimum SMETS1 Services or increase transaction times by routing through successive layers of infrastructure. When considering whether to enrol SMETS1 meters into DCC services, users are likely to offset any outstanding planned return from their SMETS1 meters against the aggregate impact of the option. This may lead to a reduction in the number of SMETS1 meters enrolled. Options may require different security measures to ensure that the residual security risk is low enough to be accepted. Security measures may have different costs and, therefore, the cost of security will vary between options. IEPFR Consultation DCC Public Page 119 of 144

120 Criteria Description Potential Influence of Options as a result of enrolment. IEPFR Consultation DCC Public Page 120 of 144

121 Appendix D Analysis of Communication Services The Minimum SMETS1 Communication Services DCC has undertaken analysis of the Minimum SMETS1 Services to understand whether the services listed could be implemented by DCC using equivalent SMETS2 DCC user interface services and whether there are other complementary services that may be required in order to fully deliver the Minimum SMETS1 Services. The analysis is based on DCC's understanding of how the services are implemented for the SMETS1 meter cohorts and feedback from suppliers indicating which services are currently in use and which services are expected to be required in future. The Minimum SMETS1 Services, as defined in Appendix F to the SEC, are listed in Table 21. Ref Description Eligible Users 1.1 Update Import Tariff (prepayment) Import Supplier, Gas Supplier 1.1 Update Import Tariff (credit) Import Supplier, Gas Supplier 1.2 Update Price (prepayment) Import Supplier, Gas Supplier 1.2 Update Price (credit) Import Supplier, Gas Supplier 1.5 Update Balance Import Supplier, Gas Supplier 1.6 Update Payment Mode Import Supplier, Gas Supplier 2.1 Update Prepay Configuration Import Supplier, Gas Supplier 2.2 Top Up Device Import Supplier, Gas Supplier 2.3 Update Debt Import Supplier, Gas Supplier 2.5 Activate Emergency Credit Import Supplier, Gas Supplier 3.2 Restrict Access CoT Import Supplier, Gas Supplier 3.3 Clear Event Log Import Supplier, Gas Supplier IEPFR Consultation DCC Public Page 121 of 144

122 4.1 Read Instantaneous Import Register Values 4.2 Read Instantaneous Export Register Values 4.3 Read Instantaneous Prepayment Register Values Import Supplier, Gas Supplier, Electricity Distributor, Gas Transporter Export Supplier, Electricity Distributor Import Supplier, Gas Supplier 4.4 Retrieve Billing Data Log Import Supplier, Gas Supplier 4.8 Read Profile Data Import Supplier, Gas Supplier, Electricity Distributor, Gas Transporter, Export Supplier, Other User 4.1 Read Network Data Import Supplier, Gas Supplier, Electricity Distributor, Gas Transporter 4.11 Read Tariff Import Supplier, Gas Supplier, Other User 4.16 Read Active Power Import Import Supplier, Electricity Distributor 6.2 Read Device Configuration Import Supplier, Gas Supplier, Electricity Distributor, Gas Transporter, Export Supplier, Registered Supplier Agent, Other User 6.4 Update Device Configuration (Load Limiting) Import Supplier, Gas Supplier 6.5 Update Device Configuration (Voltage) 6.6 Update Device Configuration (Gas Conversion) 6.7 Update Device Configuration (Gas Flow) 6.8 Update Device Configuration (Billing Calendar) Electricity Distributor Gas Supplier Gas Supplier Import Supplier, Gas Supplier 6.11 Synchronise Clock Import Supplier, Gas Supplier 6.12 Update Device Configuration (Instantaneous Power Threshold) Import Supplier, Gas Supplier 6.13 Read Event or Security Log Import Supplier, Gas Supplier, Electricity Distributor, Gas Transporter, Registered Supplier Agent IEPFR Consultation DCC Public Page 122 of 144

123 6.15 Update Security Credentials Import Supplier, Gas Supplier, Electricity Distributor, Gas Transporter 6.23 Update Security Credentials (CoS) Import Supplier, Gas Supplier 7.1 Enable Supply Import Supplier 7.2 Disable Supply Import Supplier, Gas Supplier 7.3 Arm Supply Import Supplier, Gas Supplier 7.4 Read Supply Status Import Supplier, Gas Supplier, Electricity Distributor, Gas Transporter, Export Supplier, Registered Supplier Agent 11.1 Update Firmware Import Supplier, Gas Supplier 11.2 Read Firmware Version Import Supplier, Gas Supplier, Electricity Distributor, Gas Transporter, Export Supplier, Registered Supplier Agent, Other User Services with Service Reference Variants Table 21 Minimum SMETS1 Communication Services Within the Minimum SMETS1 Services, there are a number of equivalent SMETS2 DUIS Service References for which multiple Variants are defined in DUIS. The relevant Service References and their Variants are listed in Table 22 along with references to the SMETS1 WAN Interface Commands that map to these service requests. If a Service Reference Variant aligns with one of the Minimum SMETS1 Communication Services and can be mapped to a SMETS1 requirement, DCC has assumed the Variant to be in scope of the Minimum SMETS1 Services (regardless of the interface option selected). This is in the interest of maintaining a consistent user experience across SMETS1 and SMETS2 meters as far as possible. Minimum SMETS1 Service (Appendix F Reference) DUIS Service Reference Variant Description SMETS1 Requirement? SMETS1 GSMS Reference SMETS1 ESMS Reference Update Import Tariff (Primary Element) Update Import Tariff (Secondary Element) Y N n/a n/a IEPFR Consultation DCC Public Page 123 of 144

124 Minimum SMETS1 Service (Appendix F Reference) DUIS Service Reference Variant Description SMETS1 Requirement? SMETS1 GSMS Reference SMETS1 ESMS Reference Update Price (Primary Element) Update Price (Secondary Element) Read Instantaneous Import Registers Read Instantaneous Import TOU Matrices Read Instantaneous Import TOU With Blocks Matrices Read Instantaneous Import Block Counters Read Active Import Profile Data Read Reactive Import Profile Data Read Device Configuration (Voltage) Read Device Configuration (Randomisation) Read Device Configuration (Billing Calendar) Read Device Configuration Y N n/a n/a Y Y N n/a n/a Y Y Y Y n/a N n/a n/a Y Y IEPFR Consultation DCC Public Page 124 of 144

125 Minimum SMETS1 Service (Appendix F Reference) DUIS Service Reference Variant Description (Identity Exc MPxN) Read Device Configuration (Instantaneous Power Thresholds) Read Device Configuration (MPxN) Read Device Configuration (Gas) Read Device Configuration (Payment Mode) Update Device Configuration (Load Limiting General Settings) Update Device Configuration (Load Limiting Counter Reset) Update Security Credentials (KRP)* Update Security Credentials (Device)* SMETS1 Requirement? SMETS1 GSMS Reference SMETS1 ESMS Reference Y n/a N n/a n/a Y n/a Y Y n/a Y n/a Y Y Table 22 Minimum SMETS1 Communication Services with Service Reference Variants * These Variants are specific to the SMETS2 end-to-end security model. A different model is proposed for the DCC SMETS1 Service. As can be seen in Table 23, there are five Service Reference Variants for which there is no equivalent SMETS1 WAN Interface Command. IEPFR Consultation DCC Public Page 125 of 144

126 Service Reference Variant Service Request Name Eligible Users Comment Update Import Tariff (Secondary Element) Update Price (Secondary Element) Read Instantaneous Import TOU With Blocks Matrices Read Device Configuration (Randomisation) Import Supplier (IS) Import Supplier (IS) Electricity Distributor (ED) Import Supplier (IS) Electricity Distributor (ED) Registered Supplier Agent (RSA) The Device Type to which this SR Variant is applicable is "Twin Element Electricity Metering Equipment" as described in SMETS2. SMETS1 does not contain any requirements relating ESMS with a secondary element so SR could not be supported by all Enrolled SMETS1 meters. DCC is aware that one of the SMETS1 meter types proposed for Enrolment does contain a secondary element. This is a special case and is outside of the requirements of SMETS1. The Tariff TOU Block Register Matrix is a required ESME Operational Data object in SMETS2 that has no equivalent in SMETS1. This SR Variant maps to the GBCS use case that reads the SMETS2 Operational Data object and therefore cannot be supported for SMETS1 meters. N.B. SMETS1 does require meters to support Time-of-Use with Block Pricing, but this is achieved by recording consumption in the Tariff TOU Register Matrix and Tariff Block Counter Matrix, which are required Operational Data objects in SMETS1. Other Variants of SR 4.1 map to GBCS use cases that read SMETS2 Operational Data objects which do have equivalents in SMETS1. SMETS2 requires an ESME to be capable of applying a Randomised Offset for Tariff, ALC and HCALC switching. Randomised Offset is not a SMETS1 requirement and no equivalent SMETS1 Configuration Data object exists, therefore this SR Variant cannot be supported by SMETS1 meters. Other Variants of SR 6.2 (except as described below) map to GBCS use cases that read SMETS2 Configuration Data objects which do IEPFR Consultation DCC Public Page 126 of 144

127 Service Reference Variant Service Request Name Read Device Configuration (MPxN) Eligible Users Import Supplier (IS) Export Supplier (ES) Gas Supplier (GS) Electricity Distributor (ED) Gas Transporter (GT) Registered Supplier Agent (RSA) Other User (OU) Comment have equivalents in SMETS1. MPxN is a Configuration Data requirement in SMETS2. It is not a SMETS1 requirement. DCC is aware that several of the SMETS1 meter types proposed for Enrolment do have the capability to store MPxN, however this is not believed to be universal and is outside of the requirements of SMETS1. Other Variants of SR 6.2 (except as described above) map to GBCS use cases that read SMETS2 Configuration Data objects which do have equivalents in SMETS1. Table 23 Minimum SMETS1 Communication Services Service Reference Variants with no equivalent SMETS1 WAN Interface Command Support by SMSOs for the Minimum SMETS1 Communication Services SMETS1 is a minimum technical specification for metering equipment and is therefore not applicable to the Head End Systems used to communicate with SMETS1 Meters or the SMSOs who operate SMETS1 meters on behalf of suppliers. SMSOs and the systems they operate for SMETS1 meters do not therefore provide universal support for the full range of meter functions defined in SMETS1. Head End System vendors (the majority of whom act as SMSOs) have implemented the services for which there is demand from energy suppliers. The list of services available from each SMSO, the way in which these services bundle low level meter commands into business process level transactions that can be called by users and the nature of the technical interfaces presented to users varies considerably. This section includes analysis of the current extent of support for the Minimum SMETS1 Communication Services by the SMSOs whose services are used by the suppliers that responded to DCC's Invitation. Gaps in the current SMSO services when compared to the Minimum SMETS1 Communication Services indicate that changes may be required to the SMSO's Head End System as part of the implementation of the DCC SMETS1 Service depending upon the Communications Services Option that is selected. This would only be relevant where the technical option selected retains the SMSO. In cases where an SMSO does support one of the Minimum SMETS1 Communication Services, the SMSO's interface may require adaptation for integration with DCC either because of the nature of the interface (e.g. file based) or because there is not a 1:1 mapping between the services provided by the SMSO and the Minimum SMETS1 Communication Services. In the latter case, where the SMSO supports one of the Minimum SMETS1 Communication Services as part of a bundle of meter commands to accomplish a business process (i.e. one SMSO service maps to IEPFR Consultation DCC Public Page 127 of 144

128 many of the Minimum SMETS1 Communication Services), then these services would need to be unbundled such that the individual service request can be accepted and processed. This is discussed in the section on integration path options. The extent of support by SMSOs for the Minimum SMETS1 Communication Services can be summarised thus (where an SMSO uses more than one Head End System to provide services, each combination of SMS and HES is treated separately, hence there are a total of 8 combinations): Service Reference Description 1.1 Update Import Tariff (prepayment) Update Import Tariff (credit) Update Price (prepayment) Update Price (credit) Update Balance Update Payment Mode Update Prepay Configuration Top Up Device Update Debt Activate Emergency Credit Restrict Access - CoT [Change Of Tenancy] Clear Event Log Read Instantaneous Import Register Values Read Instantaneous Export Register Values Read Instantaneous Prepayment Register Values Retrieve Billing Data Log Read Profile Data Read Network Data Read Tariff Read Active Power Import Read Device Configuration Update Device Configuration (Load Limiting) Update Device Configuration (Voltage) Update Device Configuration (Gas Conversion) Update Device Configuration (Gas Flow) 2 Number of SMSO/ HESs that currently support the service in some form (of a total of 8) IEPFR Consultation DCC Public Page 128 of 144

129 6.8 Update Device Configuration (Billing Calendar) Synchronise Clock Update Device Configuration (Instantaneous Power Threshold) Read Event Or Security Log Update Security Credentials Update Security Credentials (CoS) Enable Supply Disable Supply Arm Supply Read Supply Status Update Firmware Read Firmware Version 4 Table 24 Support by SMSOs for the Minimum SMETS1 Communication Services Commissioning Eligible Meters first in DCC Context With reference to BEIS's letter of 24 March 2016 to SEC energy suppliers, entitled 'MAINTENANCE OF SMETS1 SMART METERING SYSTEMS AFTER THE SMETS1 END-DATE' commissioning services are fundamental to the fulfilment of BEIS's policy that energy suppliers should be able to undertake maintenance of SMETS1 Smart Metering Systems after the SMETS1 End Date. Replacement of any component or device that forms part of the Smart Metering System will involve some process of commissioning such that the new component or device can function and that the Smart Metering System remains compliant with SMETS1. The implication of this policy for any SMETS1 Smart Metering System that is Enrolled into DCC is that, in order for a supplier user to undertake maintenance of that Smart Metering System, commissioning services will be required as part of the SMETS1 Services, in addition to whichever of the Communication Services Options is selected. There are a number of service requests listed in Table 25 that are required to accomplish commissioning of SMETS2 Smart Metering Systems, which will always comprise Communications Hub Function (CHF), Electricity Smart Metering Equipment (ESME) and/or Gas Proxy Function (GPF) and Gas Smart Metering Equipment (GSME) and may include Type 1 Devices and and/or Type 2 Devices. Type 2 Devices such as IHDs, which do not have a status recorded in the Smart Metering Inventory, are not subject to the Inventory Enrolment and Withdrawal Procedures and do not need to be Commissioned in the sense defined by the SEC (i.e. the "Commission" service is not used). Service requests 12.2, 8.11, are required to bring Type 2 Devices into service and would also be provided for commissioning of IHDs as part of the DCC SMETS1 Service. Service Reference Description Comment IEPFR Consultation DCC Public Page 129 of 144

130 Service Reference Description Comment 12.2 Device Prenotification Update HAN Device Log Commission Device Join Service (Critical) Join Service (Non- Critical) Set Device Configuration (Import MPxN) Needed for SMETS1 and will require additional data items if new SMETS1 devices are to be added and/ or if complete asset data set for all assets to be Enrolled is not loaded to DCC systems outside of DUIS (e.g. IMSI). A mechanism is needed to initiate activation of a SIM in CHF. Needed to enable whitelisting of SMETS1 devices on communications hubs. Needed to mark SMETS1 meters as Commissioned in the SMI. An equivalent may be needed to enable SMETS1 meters to authenticate PPMID-like devices that join the HAN. In the case of SMETS1, this would not be a Critical command, as there would be no GBCS Pre- Command to return to the user for signing. An equivalent may be needed to enable SMETS1 meters to authenticate IHDs that join the HAN. Not a SMETS1 requirement, however more than one meter type supports this and it is in use by more than one Supplier. 8.4 Update Inventory Non-Device Request. May be used to set status of a CHF to 'Commissioned'. Table 25 DUIS Service Requests involved in commissioning SMETS2 Smart Metering Systems SMETS2 Communications Hubs, which are supplied by DCC, are pre-populated in the Smart Metering Inventory by DCC and the CHF status automatically set to 'Commissioned' once the Communications Hub joins the SM WAN. SMETS1 does not define a Communications Hub Function (CHF) as a discrete device type, instead listing WAN Interface requirements against Electricity Smart Metering Systems and Gas Smart Metering Systems (both referred to below as "Meters"). Nor does SMETS1 define a Gas Proxy Function (GPF). In practice, DCC is aware that all SMETS1 Smart Metering Systems that form the cohorts currently under consideration use a HAN based on the ZigBee Smart Energy Profile (SEP) and have a communications hub (intimate or physically separate from the electricity meter), which is analogous to the CHF Device Type. The widespread use of ZigBee among the meter cohorts under consideration indicates that all will require a similar set of commands to whitelist devices to enable them to join the HAN and therefore use of Services equivalent to those listed would be widely supportable. Several of the communications hubs deployed by suppliers are also known to use mirroring to store and provide access to data from sleepy battery powered Gas meters, which is analogous to the GPF. IEPFR Consultation DCC Public Page 130 of 144

131 As-Is SMSO commissioning services for SMETS1 Meters Head End System vendors have taken a variety of different approaches to commissioning SMETS1 meters. These include: use of a Hand-Held Terminal that communicates directly with the communications hub to orchestrate joining of devices to the HAN and to request commissioning commands for each device from the HES; commissioning is initiated from the HES as a series of requests via its user interface (manual or automated) to join devices to the HAN and send commissioning commands; commissioning is initiated from the meter by entering an MPxN into the Meter's user interface to join meters to the HAN and request commissioning commands from the HES; in some cases, the request to commission a device results in the HES sending a series of commands that apply configuration parameters specific to the device type and, in the case of meters, set the payment mode and tariff, which must be created and linked to the MPxN in the HES prior to commissioning; in other cases, the commands to configure devices are requested separately by the user; and in all cases, devices must be known to the HES prior to their commissioning and, in the case of communications hub, the SIM must be activated via the S1CSP's management portal or API. DCC commissioning services for SMETS1 Meters DCC considers that a SMETS1 commissioning capability should be provided as a set of communication services and non-device services that are common to all Eligible Meter types and are in a format that is the same as that for the existing equivalent DCC user interface services. If a standardised approach is adopted to commissioning service requests, in the case of integration path 5 which uses SMSO services, it will be necessary to make changes to any HES that currently bundles together the relevant meter commands with other types of command. This is so that that the meter commands executed by the HES in order to commission a SMETS1 meter are aligned with the equivalent service request submitted by the user. Decommissioning Enrolled SMETS1 Meters Decommissioning via DCC means submitting a Decommission service request that results in an update to the Smart Meter Inventory, changing the status of the Device to "decommissioned" and disassociating the device from the MPxN there is no interaction with the Device. Service request 8.3 "Decommission Device" is not included in the Minimum SMETS1 Communication Services. Type 2 Devices, such as IHDs, do not have a Device SMI Status recorded within the Smart Meter Inventory; therefore no service request exists for decommissioning of such Devices. In SMETS2, PPMIDs, a Device type that is not recognised in SMETS1, are also decommissioned through the use of service request 8.3. Some SMETS1 IHDs deployed along with the meter cohorts under consideration have similar functionality to that of a PPMID. IEPFR Consultation DCC Public Page 131 of 144

132 If a SMETS1 device is to be replaced (rather than permanent decommissioning of the entire smart metering system) and/or if a device is intended to be returned to stock for re-deployment, it is necessary to unjoin Devices from the HAN prior to decommissioning so that the smart metering system can be brought back into operation using remote commands. The relevant service requests to enable this are not included in the Minimum SMETS1 Communication Services. For SMETS2 those are shown in Table 26 below: Service Reference Description Comment Unjoin Service (Critical) Unjoin Service (Non-critical) Used to remove: A PPMID from the Device Log of an ESME or GSME; and An ESME from the Device Log of an HCALCS. Used to remove: A Type 2 Device (e.g. IHD) from the Device Log of an ESME or GPF; An ESME or GSME from the Device Log of a PPMID; A GPF from the Device Log of a GSME; and A PPMID from the Device Log of a GPF. Table 26 Service Requests required to Decommission Enrolled SMETS1 Meters In the context of decommissioning, service request 8.11 "Update HAN Device Log" is used to remove devices from a CHF Whitelist. In the current solutions used to operate SMETS1 meters, there are a number of approaches to decommissioning: most known Head End Systems (HES) bundle other commands into a business process level transaction for device removal, rather than offering discrete commands that align with the service requests listed above; in some cases device removal is initiated by the Head End System (HES), whilst other solutions utilise a Hand Held Terminal (HHT) carried by the meter installer or manual entry of a removal code by the installer; and HHTs that establish direct communication with SMETS1 devices to issue commands will not be supported by DCC. Per section of the DUIS, "where a user wishes to decommission a Device and re-use the Device at another premise then the DCC Service user must not use the Update Inventory service request to perform this activity. Instead, a service request 8.3 Decommission Device (see section ) should be used to update the Device SMI Status to Decommissioned followed by a subsequent service request 12.2 Device Pre-notification (see section 0) to update the Device SMI Status to Pending. The Device can then be commissioned as per normal process." Device Prenotification is dealt with in the section above. DCC considers that Services equivalent to service requests 8.3, 8.8.1, and 8.11 should be provided as part of the DCC SMETS1 Service to enable decommissioning. IEPFR Consultation DCC Public Page 132 of 144

133 Should a standardised approach be taken to decommissioning service requests, in the case of an integration path that uses SMSO services, it will be necessary to make changes to any HES that currently bundles together the relevant meter commands with other types of command. This is so that that the meter commands executed by the HES during decommissioning of Enrolled SMETS1 meters are aligned with the equivalent service request submitted by the user. IEPFR Consultation DCC Public Page 133 of 144

134 Appendix E Current SMETS1 vs. SMETS2 model for Prepayment The differences between the various retail models for consumers with SMETS1 prepayment meters and the future model for SMETS2 prepayment meters are explored below. There are various models for delivering a functioning end-to-end prepayment solution for topping up SMETS1 meters. To aid understanding of the current heterogeneous market, Table 27 lists the key participants and the roles that each may fulfil in the different prepayment models for SMETS1 meters this diversity is illustrated in Figure 24. For comparison, the table also includes the roles that each participant may expect to play in the prepayment model for SMETS2 meters, illustrated in Figure24. Participant Consumer Payment Services Provider (PSP) e.g. Paypoint, Payzone, Post Office Energy Supplier Role in prepayment model for SMETS1 Meters (as-is) See Figure 10 Purchases top up in person or online, providing PAN (also known as PCN or SCN) which uniquely links the customer to the target SMETS1 meter Provides the supplier with access to a network of retail outlets capable of accepting payments for top ups. May also provide supplier with 'white label' online/ mobile payment services for top ups. During top up transaction: Requests UTRN from SMSO or energy supplier as part of a one step process that also triggers the SMSO/energy supplier to send Add Credit Command to meter. Provides UTRN to consumer at point of sale. May have in-house payment infrastructure to retail direct to consumer (e.g. via website) obtains UTRN to provide to consumer as part of transaction. May have capability to generate UTRNs in-house (either to fulfil direct sales, or through PSP channels) using algorithms provided by manufacturer(s) of supported SMETS1 meters and security credentials held on meter. May request UTRN from SMSO, as part of a one step process that also Role in prepayment model for SMETS2 Meters See Figure 11 Same as for SMETS1. Similar to SMETS model, except: During top up transaction: Requests UTRN from energy supplier (or a nominated third party), as the first stage in a two-step process for applying top ups to meters. May generate UTRNs in-house using GBCS algorithm and own security credentials. May obtain UTRNs from a third party with whom the supplier shares its security credentials for UTRN generation. Submits Top Up Device service requests via DUIS to send UTRNs to SMETS2 meters. IEPFR Consultation DCC Public Page 134 of 144

135 Participant SMSO Head End System vendor Meter manufacturer SMETS1 CSP DCC (including DSP and CSPs) Role in prepayment model for SMETS1 Meters (as-is) See Figure 10 triggers the SMSO to send Add Credit Command to meter. May only receive periodic financial settlements and reconciliation reports from SMSO and/or PSP. May have capability to generate UTRNs using algorithms provided by manufacturer(s) of supported SMETS1 meters and security credentials held on meter. Forms and sends Add Credit Commands to deliver UTRNs to SMETS1 meters, on receipt of request from PSP or supplier (which may or may not include the UTRN). May develop software to generate UTRNs using algorithms provided by manufacturer(s) of supported SMETS1 meters. Develops software to convey UTRNs to SMETS1 Meters as part of an Add Credit Command. Specifies the algorithm to be used to generate UTRNs for its SMETS1 meters. Conveys Add Credit Commands to SMETS1 Smart Metering System's WAN Interface. No role in SMETS1 as-is. Role in prepayment model for SMETS2 Meters See Figure 11 No role in SMETS2. No role in SMETS2. Implements UTRN algorithm as specified in GBCS. No role in SMETS2. Forms and conveys Add Credit Commands to deliver UTRNs to SMETS2 meter's HAN Interface, on receipt of Top Up Device service request (which includes the UTRN). Table 27 Organisations involved in prepayment solutions for Smart Meters IEPFR Consultation DCC Public Page 135 of 144

136 Top Up UTRN SMSO UTRN PAN & Top Up Command Payment Service Provider UTRN PAN & UTRN PAN & Top Up Command Consumer PAN & PAN & UTRN Energy Suppliers Colour coding of arrows corresponds to the party providing the data specified in the arrow s caption Figure 23 As-is prepayment models for SMETS1 Meters IEPFR Consultation DCC Public Page 136 of 144

137 Top Up SMETS1 Capabilities UTRN PAN & Payment Service Provider UTRN PAN & Top Up Service Request + UTRN Consumer DCC Users Figure 24 Prepayment model for SMETS2 Meters IEPFR Consultation DCC Public Page 137 of 144