Conclusions on DCC s Consultation on the proposed changes to the SEC Subsidiary Documents that define DCC s SMETS1 Services

Conclusions on DCC s Consultation on the proposed changes to the SEC Subsidiary Documents that define DCC s SMETS1 Services Date: 14 February 2018 Classification: DCC Public

Table of Contents 1. Introduction...3 2. DCC Conclusions in light of Consultation Responses...3 3. Conclusions and Next Steps... 12 Appendix A Summary of SRPD changes (Supplementary changes arising from consideration of consultation comments and ongoing development)... 14 Appendix B Summary of DUIS changes (Supplementary changes arising from consideration of consultation comments and ongoing development)... 14 Appendix C Summary of MMC changes (Supplementary changes arising from consideration of consultation comments and ongoing development)... 15 Appendix D Summary of S1SR changes (Supplementary changes arising from consideration of consultation comments and ongoing development)... 15

1. Introduction In the initial stages of the smart meter roll-out across Great Britain, a number of energy suppliers are installing first generation smart devices (known as SMETS1 devices) in consumers premises. SMETS1 devices installed by one energy supplier, however, are not always interoperable with and supported by the systems used by another supplier. The Data Communications Company (DCC) has developed a plan and designed a solution for the incorporation of such devices into its national network. It provides important shared benefits for industry and consumers, and intends to offer the ability for SMETS1 consumers to maintain their smart services following a decision to switch suppliers. The next generation of smart meters (known as SMETS2 meters) will be operated via the DCC s national network from the outset and allow smart switching between suppliers as standard. During the course of 2017, DCC has engaged with its customers to develop and refine the design of the SMETS1 Service, and has used this design to inform the drafting of the SEC Subsidiary Documents (SSDs). On 14 November 2017, DCC issued a consultation on the first tranche of amendments to the SSDs that will, in conjunction with any consequential amendments to the main sections of the SEC, 1 define the User impacting elements of DCC s SMETS1 Services. This consultation comprised amendments to the following documents: Service Request Processing Document (SRPD); DCC User Interface Specification (DUIS); Message Mapping Catalogue (MMC); Inventory Enrolment and Withdrawal Procedure (IEWP); Organisation Certificate Policy (OCP); SMKI Interface Design Specification (SMKI IDS); CPL Requirements Document (CPL); and SMETS 1 Supporting Requirements (S1SR) - a new SSD documenting the requirements in relation to SMETS1 Devices. This document sets out DCC s conclusions in light of the consultation feedback, and provides a summary of the key comments that have been raised by industry as well as DCC s responses to those comments. Where appropriate, the SSDs have been updated and revised in light of the consultation feedback as well as any outstanding issues which have previously been identified throughout engagement with industry prior to the launch of this consultation. Section 2 of this document provides an overview of the consultation comments and responses, together with a description of the proposed post-consultation changes to the SSDs. 2. DCC Conclusions in light of Consultation Responses Within its consultation, DCC requested that industry consider ten specific questions to which in total 12 organisations responded. Respondent groups included large, distribution networks, trade associations, a small energy supplier as well as other smart metering market participants. It should be noted that DCC previously consulted on proposed changes to the Organisation Certificate Policy and the SMKI Interface Design Specification as part of the subsidiary 1 SEC Main Body changes in support of SMETS1 are due to be consulted on separately in due course.

document changes needed to support Enrolment and Adoption. DCC notes that BEIS is proposing to consult on SEC changes to permit DCC to carry out Production Proving and that these changes include the changes to these two documents that would be needed to support Enrolment and Adoption. For the time being it is assumed that the changes to these two documents will be progressed as part of Production Proving and consequently changes to them have not been included in the set of documents put forward for baselining. If this situation changes (i.e. if the changes are no longer to be progressed as part of Production Proving) then the necessary changes would be brought back under the aegis of the Enrolment and Adoption work and progressed accordingly. The responses to the relevant questions on these two documents (Organisation Certificate Policy and the SMKI Interface Design Specification) are included in this response document for completeness. 2.1 Consultation Responses and post-consultation Changes Where appropriate, the SSDs have been updated and revised in light of the consultation comments as well as any outstanding issues which have previously been identified through engagement with industry prior to the launch of this consultation. The following sections provide an overview for each of the consultation questions, of the post-consultation changes that are being proposed, and the number and nature of respondent groups that have commented. Separately, it should be noted that prior to and during the consultation, DCC identified a minor number of anomalies and/or discrepancies in respect of the SRPD, DUIS, MMC and S1SR documents. For the avoidance of doubt, none of these issues compromise in any way the overall SMETS1 Services solution as previously presented to industry. The changes being proposed to these documents are listed in Appendices A, B, C and D respectively. 2.1.1 Question 1 DCC asked consultees: [Question 1] Do you have any comments on the proposed changes to SRPD? Please provide a rationale for your views. In total, 11 parties responded to Question 1 directly. Respondent groups included large energy suppliers, a small energy supplier, a trade association as well as another smart metering market participant. An overview of the key issues raised in response to this question is summarised below. Eight respondents, including four large energy suppliers, two distributed network operators, one trade association and one other smart metering market participant, asked for greater clarity around the threshold anomaly detection rules which will be applicable to SMETS1. From those eight respondents, five respondents (including 3 large energy suppliers, one distributed network operator and one trade organisation) expressed several concerns about the deletion, without notification to Users, of SMETS1 Service Requests that failed Threshold Anomaly Detection checks. DCC acknowledges the concerns raised by industry in this area, and confirms that the potential future use of an S1SP Alert to notify Users when SMETS1 Service Requests are being deleted following a breach of an Anomaly Detection Threshold is being explored with our service providers. However, this would not affect the drafting as alert codes are not set out within the SSDs. Three respondents, including three large energy suppliers and one trade organisation, commented that insufficient protections were in place to prevent a gas meter, installed at a dual fuel site supplied by a different electricity supplier, from being inadvertently stranded following the deployment of new firmware on the Communication Hub. Whilst welcoming the

introduction of a new DCC alert, one respondent noted that the time window between this alert and the activation of the firmware on the communications hub would be too short to enable the gas supplier to update the firmware on the gas meter. Whilst recognising the concerns which industry has in this regard, DCC notes that the rights and responsibilities in respect of these matters will be consulted upon separately by BEIS in due course, and set out in the main body of the SEC. Two respondents, including one small and one large energy supplier, requested additional clarity around the production of UTRNs. In particular one large and one small energy Supplier expressed a preference in the generation of UTRNs being supported through a separate interface as opposed to the use of an existing Service Request (SRV 2.2), as per the current design. In expressing this view, respondents raised concerns around the performance and availability of the DCC User Interface and the processing of Service Requests downstream, as well as the complexity associated to re-using of SRV 2.2. DCC acknowledges the interest that a number of industry parties have expressed in the use of a separate interface for UTRN generation and we are currently carrying out an impact assessment of this design option. DCC will share this information with Users when it is available in March 2018. In line with the provision of services through the existing interface DCC proposes that, as consulted, the modification to SRV2.2 is retained within the baselined SSDs. Should subsequently a new separate interface for UTRN generation be provided, the requirements for interfacing to it will need be documented within the SEC framework, as part of the interface development work and further consultation on any such changes would be undertaken in due course. Two respondents, including one large energy supplier and one trade association, requested clarity from DCC on how it intends to appropriately manage and protect the processing of SMETS1 Service Requests that may potentially contain personal and sensitive data. DCC recognises the concerns raised by industry in this regard. DCC has since set out its proposed protections for personal data in a Data Privacy Solution Options Appraisal RFI to energy suppliers (Data Controllers), which was launched on the 7 February 2018 and closes on 21 Feb 2018.The protections proposed are consistent with the drafting of the SSDs. The following change is being proposed to the SRPD document as a result of the consultation responses: A distribution network operator commented that it would be more appropriate to state at the start, rather than at the end, of section 8 (Obligations of the DCC: 'CoS Update Security Credentials' Service Requests and Corresponding Pre-Commands) that it does not apply to SMETS1. DCC agrees with the respondent s comment that this statement should be made at the start of clause 8 as opposed to the end of this clause. 2.1.2 Question 2 DCC asked consultees: [Question 2] Do you have any comments on the proposed changes to DUIS? Please provide a rationale for your views. In total, 12 parties responded to Question 2. Respondent groups included large energy suppliers, distribution network operators, a small energy supplier, a trade association as well as other smart metering market participants. A summary of the key issues raised in response to this question is set out below. Five large energy suppliers and one trade association raised specific concerns about the TRTs for the SMETS1 Services that are yet to be determined, noting that having early sight

of the applicable TRTs is considered to be critical from a business processes perspective. DCC notes that it has engaged with Users to discuss its initial thinking around TRTs for SMETS1 Services. DCC has shared its views on the incompatibility of SMETS2 TRTs with SMETS1 Services, due to the inherent limitations of the WAN networks that will be reused in the delivery of SMETS1 Services. Whilst performance levels for the HAN and WAN are unlikely to be included in a DCC TRT measure, DCC can confirm that service levels in regards to Service Request processing will be determined and negotiated as part of the procurement of enduring services in the next period of the programme. DCC s obligations around TRTs will be subject to a public consultation at a later date. Four large energy Suppliers were concerned that the consultation omitted the means by which SMETS1 Elective Communication Services will be provided, managed and operated. More explicitly in this regard, respondents often raised concerns about their ability to deliver firmware and configuration updates to IHDs and PPMIDs which are installed at customers premises, and deemed necessary to ensure the continued operation of these devices. Whilst recognising the industry's concerns in respect of Elective Communication Services for SMETS1, DCC notes that these arrangements are out of scope of this consultation. Instead, DCC notes that any Elective Communication Services will need to be taken up on a bilateral basis. DCC has provided BEIS with a validated set of customer requests for Elective Communication Services together with an initial outline estimate of timescale impacts. Two large energy suppliers requested that additional clarity is provided by DCC on how it intends to manage competing demands from different energy suppliers for the processing of Critical Service Requests. DCC shall maintain a high level of reliability whilst scheduling and activating SRVs at the time / date specified and are procuring new DCC system components that can scale to meet capacity requirements. We expect the behaviour of DCC system components (e.g. prioritisation, future dating) to be driven by Service Levels, including TRTs which will be included in the SEC. As per the comments to Question 1, respondents also expressed a general preference for the generation of UTRNs to be supported through a separate interface as opposed to the use of DUIS for that purpose. The issue was raised by seven respondents in total, including four large and one small energy suppliers, one trade association and one other smart metering market participant. DCC s response to this comment is in line with its response set out for Question 1. One large energy supplier raised concerns around proposed scope of SRVs (i.e. that there are 72 SRVs). The respondent in question expressed a preference in mandating SMETS1 compliant assets to support the core services as set out in the IEPFR, derived from Appendix F to the SEC, and for all other commands to be optional. The respondent noted that where a Supplier has tested and assured a device as SMETS1 compliant but the device does not support any of the 23 non-core SRVs, the Supplier may be required to deploy firmware upgrades to such devices or risk that these devices become stranded. DCC recognises that DUIS captures the full extent of the core communication services for DCC s Service in support of S1 devices, based on the functionality specified in SMETS1. DCC will continue to monitor and review the viability of these communication services during its development and testing and will engage Users as required through appropriate governance. The following changes are being proposed to the DUIS document as a result of the consultation responses: One large energy supplier noted that figure 4 of clause 3.4.1 incorrectly refers to schemaversion 2.0 as opposed to schemaversion 3.0. DCC agrees with the respondent s view and legal text will be updated accordingly;

One large energy supplier noted that the Firmware Image maxlength has increased x10 to ~10M (10240000 as opposed to the description of E110105 which states 1024000. DCC notes that Firmware Image maxlength in the Schema has increased which has the effect of allowing larger Firmware Images than would be permissible for SMETS2+ to pass DCC Schema validation. The wording of E110105 has been updated to clarify that this error will be used to indicate that SMETS2+ Firmware Images exceeds the permissible size; One large energy supplier noted that table 23 had not been updated in light SRV command variants which are applicable and/or not supported for SMETS1. DCC agrees with the respondent s view and has updated the table accordingly; and One large energy supplier noted that the cross reference to the Response code valid values had erroneously been removed. DCC agrees with the respondent s view and legal text will be updated accordingly. 2.1.3 Question 3 DCC asked consultees: [Question 3] Do you have any comments on the proposed changes to MMC? Please provide a rationale for your views. In total, five parties responded to Question 3 directly. Respondent groups included large energy suppliers, distribution network operators and another smart metering market participant. An overview of the key issues raised in response to this question is summarised below. One large energy supplier raised concerns about the pending review of the security architecture imposing a potential risk to the overall SMETS1 Services solution. Whilst acknowledging the concerns raised by industry in this area, DCC notes that both the Security Sub-Committee (SSC) and SMKI Policy Management Authority (SMKI PMA) have been consulted on the proposed security architecture for SMETS1 Services. This engagement has not identified any required modifications to the consulted SSDs. However, DCC will continue to review security requirements and developments and where any requirements arise that will affect the design and so the SSDs, will use the appropriate governance mechanisms to manage any future changes. As per the comments to previous questions: One large energy supplier requested clarity from DCC on how it intends to appropriately manage and protect the processing of SMETS1 Service Requests that may potentially contain personal and sensitive data. DCC s response to this comment is in line with its response to Question 1; One large energy supplier raised general concerns around the consultation omitting the means by which SMETS1 Elective Communication Services will be provided, managed and operated. DCC s response to this comment is in line with its response to Question 2. One change is being proposed to the MMC document as a result of the consultation responses:

One large energy supplier noted that the DebugInfo group has a SMETS1Debug element which has an Error element which states (Table 1) that the valid values shall be defined in the S1SR document. The S1SR document currently does not hold such values. DCC agrees with the points raised in the response and the MMC will be updated, as the relevant information becomes available with relevant SMETS 1 specific error status data. 2.1.4 Question 4 DCC asked consultees: [Question 4] Do you have any comments on the proposed changes to IEWP? Please provide a rationale for your views. In total, seven parties responded to Question 4 directly. Respondent groups included large energy suppliers, one small energy supplier, a trade association as well as another smart metering market participant. An overview of the key issues raised in response to this question is summarised below. Four respondents, including three large energy suppliers and one trade association, requested additional clarity around the proposed pre-commissioning obligation within the IEWP, which requires Users to contact the Service Desk to provide device-specific information prior to adding a SMETS1 Device to the Smart Metering Inventory (SMI). Respondents expressed the view that they would expect this data to be provided to DCC on a meter cohort basis, rather than on an individual SMETS1 Device basis. DCC notes that the IEWP seeks to set out the enduring arrangements to support the commissioning of new devices to replace elements of a Smart Metering System once that Smart Metering System has been migrated and enrolled in DCC, and so will need be on a device specific basis. Provisions for the large scale migration of Smart Metering Systems will be laid out in the Transition and Migration Approach Document (TMAD). In respect of the device specific information that Users are required to provide to DCC prior to adding a SMETS1 Device to the SMI, clause 3.4 of the IEWP requires that this information includes the Device ID as well as any information the DCC reasonably requires in relation to that Device. Five respondents, including three large energy suppliers, one small energy supplier and one trade association, requested a more explicit understanding of what level of detail DCC would reasonably require as part of this obligation. DCC notes that as per the obligation in the IEWP, the nature and format of the information that it shall reasonably require from Users prior to adding a SMETS1 Device to the SMI shall be made available by the DCC via the Self-Service Interface. One small energy supplier asked whether they would be expected to install a SMETS2+ device if they had been unable to communicate with a SMETS1 device. DCC notes that the eligibility criteria for devices will be set out in TMAD, which will include the ability to communicate with the WAN. It should be noted that the primary intent of this clause is to ensure that the replacement device is able to communicate with the DCC. More generally, the obligations on that may fall on energy suppliers in the event that it is not possible to successfully enrol a SMETS1 device into DCC s Systems is a matter that is outside the scope of the SSDs and instead a matter for licence conditions and/or the SEC. One large energy supplier requested that greater clarity is provided around the responsibilities for pre-commissioning SMETS1 devices that have been subject to Change of Supply (CoS) following installation. DCC recognises that there may be scenarios where a device is pre-notified and the site subsequently churns, in which case the notifying supplier shall be expected to determine whether status remains as pending or remove.

The following change is being proposed to the MMC document as a result of the consultation responses: One large energy supplier noted that the lead Supplier should be able to set the status of a Communications Hub to decommissioned after the removal of the a SMETS1 Communications Hub as it may only become apparent that the Communications Hub requires replacement at a site visit and therefore may be removed prior to the update of the status. DCC agrees with the respondent s view and proposes to amend the legal drafting of clause 10.1 to reflect that the SMI status of the CHF can be set to decommissioned by the lead supplier at the point of removal or immediately after the removal of a SMETS1 Communications Hub. 2.1.5 Question 5 DCC asked consultees: [Question 5] Do you have any comments on the proposed changes to OCP? Please provide a rationale for your views. In total, three parties responded to Question 5 directly. Respondent groups included a large energy supplier, a trade associations and another smart metering market participant. An overview of the key issues raised in response to this question is summarised below. As per previous comments, all three respondents raised concerns about the pending review of the security architecture imposing a potential risk to overall SMETS1 Services solution. DCC s response to this comment is in line with its response to Question 3. No changes to those proposed to the OCP were identified as a result of the consultation responses. However, as noted in Section 2, DCC now understands that BEIS is proposing to make the changes identified as being required to the OCP as part of its Production Proving proposals. For the time being we have therefore excluded the changes to the OCP from the set of documents that need to be further amended to support Enrolment and Adoption. If the Production Proving proposals do not progress we would introduce these changes at a later stage. 2.1.6 Question 6 DCC asked consultees: [Question 6] Do you have any comments on the proposed changes to SMKI IDS? Please provide a rationale for your views. In total, four parties responded to Question 6 directly. Respondent groups included a large energy supplier, a trade association, a distributed network operator and another smart metering market participant. An overview of the key issues raised in response to this question is summarised below. As per previous comments, all four respondents raised concerns about the pending review of the security architecture imposing a potential risk to overall SMETS1 Services solution. DCC s response to this comment is in line with its response to Question 3. No changes to those proposed to the SMKI IDS were identified as a result of the consultation. As with the OCP changes, DCC notes that BEIS is proposing to implement the changes identified as being required as part of the package of changes for Production Proving and, on the assumption that these are progressed, has removed the SMKI IDS from the scope of documents that need to be further amended to support Enrolment and Adoption.

2.1.7 Question 7 DCC asked consultees: [Question 7] Do you have any comments on the proposed changes to CPL Requirements document? Please provide a rationale for your views. In total, five parties responded to Question 7 directly. Respondent groups included two large energy suppliers, one small energy suppliers, a distributed network operator and another smart metering market participant. An overview of the key issues raised in response to this question is summarised below. One small energy supplier asked for greater clarity around whose responsibility it would be to determine SMETS1 compliance in the event of a dispute between energy suppliers. DCC notes that the rights and responsibilities in respect of SMETS1 compliance will be set out in section F of the SEC main body. SEC main body changes in support of SMETS1 will be consulted upon separately by BEIS in due course. One small energy supplier requested greater clarity on how DCC would manage firmware upgrades to SMETS1 Smart Metering Systems that have already been added to the Deployed Product List, and whether such devices would need to be retested. The arrangements in respect of the SMETS1 Eligible Product Combinations list (formerly referred to as the DPL) will be covered off in section F of the SEC main body. SEC main body changes in support of SMETS1 will be consulted upon separately by BEIS in due course As per Question 3, one large energy supplier raised concerns about the pending review of the security architecture imposing a potential risk to overall SMETS1 Services solution. DCC s response to this comment is in line with its response to Question 3. The following minor typographic changes are being proposed to the CPL document as a result of the consultation responses: To link last sentence of clause 3 to clause 3.3(c) (ii); and To correct the term Successfully Execute to Successfully Executed as per the defined term in Section A of the SEC. 2.1.8 Question 8 DCC asked consultees: [Question 8] Do you have any comments on the proposed changes to S1SR? Please provide a rationale for your views. In total, eight parties responded to Question 8 directly. Respondent groups included large energy suppliers, a small energy supplier, a trade association as well as another smart metering market participant. An overview of the key issues raised in response to this question is summarised below. Two large energy suppliers raised various specific comments in relation to DCC s obligation to the processing of SMETS1 Service Requests in light of the different requirements and device functionality set out in the S1SR document. The full nature of these comments and DCC s responses are set out in Attachment 1. DCC notes that a need for additional Device Model specific processing provisions might arise as part of the ongoing Enrolment and Adoption development work. Where required, these provisions would be captured within these SSDs.

Three large energy suppliers asked various specific questions in relation to the SMETS1 requirements which exist for Devices to detect events and the associated alerting and logging requirements. The full nature of these comments and DCC s responses are set out in Attachment 1. The following changes are being proposed to the S1SR document as a result of the consultation responses: One large energy supplier noted that the cross-reference within this clause 6.3(b) is incorrect. DCC agrees with the respondent s view and legal text will be updated accordingly; One large energy supplies noted in respect of clause 8 that the Average RMS voltage alerts in SMETS1 and SMETS2+ meters have the same name but are defined differently, and should therefore be managed differently. The respondent in question expressed a preference for the respective alert to be allocated a separate SMETS1 alert code. DCC agrees with the respondent s view and proposes to allocate a different alert code to the Average RMS voltage alert; One large energy supplier noted that Table 2 contained several GBCSHexadecimalMessageCode or GBCSHexAlertCode/LogCode references as to be confirmed. DCC confirms that these codes have been updated and incorporated into the S1SR document; and Two large energy suppliers commented that clause 17 was incomplete and requires updating. DCC proposes to remove section 17 of the S1SR document. Instead a statement is being included in section 1 of the document to note that additional requirements that are specific to a SMETS1 Device Model or combination of SMETS1 Device Models will be set out in a separate appendix at a later stage. 2.1.9 Question 9 DCC asked consultees: [Question 9] Do you agree that no changes are required to TADP? In total, three parties responded to Question 9. Respondent groups included a large energy supplier, a distributed network operator and another smart metering market participant. A summary of the key issues raised in response to this question is set out below. Throughout the consultation two respondents, including one large energy supplier and another smart metering market participant responded positively to Question 9. One large energy supplier noted that it was unclear as to whether a different approach had been introduced across SMETS1 and SMETS2+ in respect of the treatment of Service Requests that fail Threshold Anomaly Detection checks. DCC notes that the same rules as for SMETS2+ shall apply for SMETS1 for volume based Anomaly Detection, meaning that no changes will be required to TADP. In line with previous comments, one other smart metering market participant commented that it was unable to respond to Question 9 in the absence of a baselined security architecture for SMETS1. No changes are proposed to the SSDs as a result of the consultation feedback to Question 9.

2.1.10 Question 10 DCC asked consultees: [Question 10] Do you have any other comments on the proposed changes to the SSDs? Are you aware of any others issues, relating to the SSDs that should be addressed and considered? In total, seven parties responded to Question 10. Respondent groups included large energy suppliers, a small energy supplier, a trade associations and another smart metering market participant. An overview of the key issues raised in response to this question is summarised below. As per the comments to previous questions: Four large energy suppliers raised general concerns around the consultation omitting the means by which SMETS1 Elective Communication Services will be provided, managed and operated. DCC s response to this comment is in line with its response set out in response to Question 2; Three large energy suppliers requested that DCC provide additional clarity regarding how it intends to manage competing demands from different energy Suppliers for the processing of Critical Service Requests. DCC s response to this comment is in line with its response set out in response to Question 2; Two large energy suppliers and one trade association re-affirmed a general preference in the generation of UTRNs being supported through a separate interface as opposed to the use of an existing Service Request (SRV 2.2) for that purpose. DCC s response to this comment is in line with its response set out in response to Question 2; One large energy supplier and one trade association raised concerns about the pending review of the security architecture imposing a potential risk to overall SMETS1 Services solution. DCC s response to this comment is in line with its response to Question 3; One large energy supplier and a trade association raised specific concerns about the TRTs for the SMETS1 Services that are yet to be determined, noting that having early sight of the applicable TRTs is considered to be critical from a business processes perspective. DCC s response to this comment is in line with its response to Question 2; and One large energy supplier requested clarity from DCC on how it intends to appropriately manage and protect the processing of SMETS1 Service Requests that may potentially contain personal and sensitive data. DCC s response to this comment is in line with its response set out in response to Question 1. No changes are proposed to the SSDs as a result of the consultation feedback to question 10. 3. Conclusions and Next Steps DCC has taken into consideration the consultation feedback, and where appropriate addressed the relevant comments made by parties. DCC considers the first tranche of SSDs to be defined to a sufficient level of detail, and to be in line with the overall solution design and security requirements relevant to the SMETS1 Services. On that basis, DCC intends to

submit these SSDs to the TBDG Enrolment and Adoption Sub-Group and request that they are added to the design baseline so additional certainty in these elements of the design may be provided, before designating (for new SSDs) and re-designating (for existing SSDs), pursuant to Condition 22 of the DCC Licence and Section X5 of the SEC. It is envisaged that the proposed changes will be incorporated into the SEC alongside the supporting changes to the main body of SEC and licence changes, which will be developed by BEIS and consulted upon in due course. The proposed changes will be incorporated into the SEC at the appropriate point in time as determined by the Secretary of State. In respect of the second tranche of SSDs to be consulted upon, DCC has identified that further amendments may be required to the following documents and is working through an impact assessment at present: Incident Management Policy (IMP); Self-Service Interface Design Specification (SSI DS); and The timings for consulting on the second tranche of SSDs will be confirmed by DCC in due course but will take place in Q2 2018. DCC anticipates that there may be a requirement to document device specific processing, which will be captured in a separate document within the regulatory framework. In addition, DCC recognises that DUIS captures the full extent of the core communication services for DCC s Service in support of S1 devices, based on the functionality specified in SMETS1. DCC will continue to monitor and review the viability of these communication services during its development and testing and will engage Users as required through appropriate governance. DCC (in liaison with its customers and BEIS) furthermore continues to develop documentation that will seek to set out testing 2 as well as transition and migration 3 arrangements. It should be noted that if as a result of any of the forthcoming consultations and/or review subsequent changes (of a non-immaterial nature) are required to the SSDs post baselining, the incorporation of such changes will be managed in accordance to the TBDG Change Process. 2 Testing arrangements will be described through the SEC Variance Testing Approach Document (SVTAD) and the relevant testing approach documents i.e. System Integration Testing Approach Document (SITAD), User Testing Services Approach Document (UTSAD), Transfer to Operations Approach Document (TTOAD), Migration Testing Approach Document (MTAD), Enduring Test Arrangements Document (ETAD) and Common Test Scenarios Document (CTSD). The SVTAD was consulted on in November 2017, and is expected to be designated in due course; consultations on SITAD and UTSAD are scheduled in quarter 1, 2018. 3 Transition and migration arrangements will be described in the Transition and Migration Approach Document, which is expected to be consulted on in Quarter 2, 2018.

Appendix A Summary of SRPD changes (Supplementary changes arising from consideration of consultation comments and ongoing development) Section Summary of Changes 16.2 (a)(ii) and (b)(ii) For Countersigned Service Request that contains a Service Request with Service Reference Variant 2.2, specify that the SMETS1 Service Provider shall be required to undertake further processing as required by the SMETS1 Supporting Requirements provided that the Threshold Anomaly Detection checks have passed; and For any other Service Request contained within a Countersigned Service Request, specify that the Equivalent Steps are taken (and that either the resultant SMETS1 Response or a SMETS1 Service Provider Alert is generated) provided that the Threshold Anomaly Detection checks have passed. Appendix B Summary of DUIS changes (Supplementary changes arising from consideration of consultation comments and ongoing development) Section Summary of Changes 1.4 Removal of the requirement that obliges the DCC to Digitally Sign the UTRN sent to Users, using a DCC Access Control Broker Private Key, where a UTRN for a SMETS1 Device is generated. DCC notes that this is not supported by the SMETS1 Services design. 1.4 Amend the statement Clause Error! Reference source not found. regarding Target Response Times shall not apply in relation to SMETS1 Devices and instead the following provisions shall apply [TBC] to Clause Error! Reference source not found. regarding Target Response Times shall not apply in relation to SMETS1 Devices. 1.4.1 Correction of the value 429967295 to 4294967295, which is the maximum size of an unsigned 32 bit integer. The value 2147483647 is given in DUIS as the maximum for xs:int, which is an unsigned 32 bit integer with half of this being 4294967295 ). To specify the values conforming to the XML types xs:positiveinteger and xs:nonnegativeinteger which be used to indicate a numerical value which the SMETS1 Device in question does not support.

Amend the statement The value 127 conforming to the XML type sr:pricescale to The value 127 conforming to the XML type ra:pricescale to reflect the corresponding MMC format XML. 3.8.10 (table 120) Removal of the weekly, monthly and quarterly DebtRecoveryRatePeriod values as these are not supported for SMETS1 (nor for SMETS2+). The schema has consequently been updated. 3.8.99.4 Inclusion of new clause 1.4.7.8 to complement clause 3.8.99.4 i.e. to specify that a SMETS1 Response to SRV 8.2 (Read Inventory) includes the calid value SMETS1 in the list of values for CSPRegion; and to include additional SMETS1 Response Data Items. 3.6.3.4 Amended clause 3.6.3 to allow N43 for all SMETS versions. DCC Alert N43 "PPMID Alert" should apply to all SMETS versions. DSP systems generate this alert based on execution status of SRV 8.11, which will be triggered irrespective of the SMETS version. Appendix C Summary of MMC changes (Supplementary changes arising from consideration of consultation comments and ongoing development) Section Summary of Changes MMC V3.0 Schema and clause 2.4 (new) Prior to issuing the consultation, DCC highlighted that the namespace changes in the latest MMC V3.0 Schema (embedded in the MMC document) require some updates to the MMC document of a detailed technical nature. At the time of issuing the consultation, DCC proposed that the existing MMC V2.0 namespace usage is retained within the text of the MMC document. DCC confirms that the respective updates to reflect the most recent MMC Schema have been applied to the MMC as part of the post consultation process/review. 1.4 (ii) b Amend the clause Timestamp shall have the meaning set out in the SMETS1 Supporting Requirements to Timestamp shall be populated as set out in the SMETS1 Supporting Requirements" Appendix D Summary of S1SR changes (Supplementary changes arising from consideration of consultation comments and ongoing development) Section Summary of Changes 2 The definition of 'Device Security Credentials' has been added to section 2 to state that in relation to a SMETS1 Device, Device Security Credentials shall include the Certificates identified by Notified Critical Supplier Certificate ID,

Notified Non-Critical Supplier Certificate ID, Notified Critical Network Operator Certificate ID and Notified Non-Critical Network Operator Certificate ID. 4.1 This clause previously required that in relation to a Update Firmware Service Request, a user includes within the Service Request its Notified Critical Supplier ID or its Notified Critical Network Operator ID (as the context requires) for the Device whose Device ID is in the BusinessTargetID field. DCC notes that this does not apply to Update Firmware Service Requests as a single Service Requests of that type could be targeted at up to 50,000 devices. Instead, DCC notes that this requirement would be needed for the Top Up Device Service Request. 4.2 This clause previously required that on request of the Update Firmware Service Request, the S1SP shall verify the user IDs specified in that Service Request. DCC however notes that this does not apply to the Update Firmware Service Request as it is not being validated. The Top Up Device Service Request however must use the Notified Critical Supplier ID, as it is subject to anti-replay checks. 12.1 This clause has been amended to set out the anti-replay protection arrangements for Service Requests that either are or are not 'Update Security Credentials (CoS) (SRV 6.23)' Service Requests. 17.40 Clause 17.40 has been amended to specify that where the DCC receives the resulting SMETS1 Response indicating success, it shall set Execution Counter values it holds in relation to the target Device and the Device Type recorded for the target Device in the Smart Metering Inventory.