We feel that the issue detailed below needs further thought and a change to the current proposals is needed:

Transcription

1 1 SSEPD Question SSEPD agrees with the updates made by the DCC to the DUIS and its schema. 1 2 SSEPD Question SSEPD is broadly supportive with the DCC's recommended approach for changing the DUIS XML Schema to support SMKI Recovery Procedure functionality in time for the DCC 1.2 release as a forward compatibility change to prevent the need to change XML schema versions between the DCC 1.2 and 1.3 Release. We feel that the issue detailed below needs further thought and a change to the current proposals is needed: We expect the DCC to automatically send alerts to all users associated with a device when it becomes compromised and the DCC changes the status held in the DCC SMI. The alerts we expect are: A DCC alert advising that the status has changed to recovery When the device id recovered a further alert advising that the device has been recovered Should the SMKI PMA reject the DCC decision to change the status to recovery (ref of the SMKI Recovery Procedure) upon the reversal of the device status (to its previous state) then we would expect an alert to notify users confirming the status that the device held prior to it being set to recovery. 2 The DCC has noted concerns raised by Network Operators during recent SMKI Recovery process and DUIS/MMC consultations regarding the absence of DCC Alerts to support the SMKI Recovery Process and has concluded that the current proposed solution could be extended to incorporate the changes suggested. The DCC recommends that these changes are progressed as part of the change process and be submitted as a change candidate for inclusion in a subsequent release of the DCC systems. On this basis, the DCC is therefore not proposing to change the current design of the DCC Systems at this point of time as part of the consultation responses for the SMKI Recovery process and DUIS/MMC consultations. The design changes to support the concerns raised by Network Operators regarding the absence of DCC Alerts to support the SMKI Recovery Process will be discussed with Users separately and agreed as part of the change process. As it is currently proposed users will need to find a method to identify and change any new device status in their systems/ processes (ref of the SMKI Recovery Procedure). This will lead to an increased cost for all users affected. 3 SSEPD Question SSEPD agree with updates made to the MMC and its associated schema 3 4 SSEPD Question SSEPD agree with the proposed versioning approach and support its implementation in all future versions of DUIS and MMC XML Schemas 4 5 SSEPD Question 5 6 SSEPD Question SSEPD generally agree with the DCC's recommended approach for the re-baselining of DUIS and MMC and the submitting of any required updates post v in order to get to a designated version of DUIS and MMC in time for DCC Live. 7 SSEPD Issue SSEPD is concerned that the timing of any new release will affect SSEPD's ability to respond to Industry Milestone specifically when the new version of Parse and Correlate management into SSEPD's live system has not been taken into account within the DCC process. 6 DCC recognises the need to minimise the impact of software releases and the number of software releases. DCC recognise and fully support several respondents comments that any release approach for MMC must also consider the delivery to users of the aligned version of P&C and designating MMC with any updates is insufficient without the delivery of the updated software release of P&C that is aligned to MMC. DCC confirm that any change to the MMC XML schema will result in an updated version of the Parse and Correlate software being made available to Users. 8 EON Question YES - We have reviewed the changes made to DUIS and it's associated schema and have no additional comments. 1 9 EON Question YES - We have reviewed the recommended approach and agree that providing the functionality as a forward compatibility change to the schema is acceptable EON Question YES - We have reviewed the changes made to MMC and it's associated schema and have no additional comments. 3

2 11 EON Question YES - We have reviewed the recommended approach and agree that it provides the necessary traceability for schema version. 12 EON Question We agree with objective the change is trying to deliver. However our preference is that the units should remain in m3 with a scalar added to the schema. Currently all gas measurements are in m3 and should remain so for consistency and prevent confusion. However we note this continues to be discussed at TSIR, and consider it an acceptable compromise as a temporary workaround 4 5 DCC note the comments. The response implies wider changes than the simple documentation update proposed. A wider solution is required to resolve which will require wider review and agreement, therefore DCC is minded to conclude that the proposed changes shall NOT be made at this point in time. 13 EON Question NO - The wording in the approach gives neither a guarantee that existing functionality will be maintained across versions, or a credible mechanism to enable prior versions of interface to be supported simultaneously. There may be significant impact to individual parties project delivery caused by external imposition of interface changes. 6 DCC is committed to supporting one previous version of the DUIS defined interface (and related DUIS/MMC schema) following a planned incremental release. The interface will respond to a Service Request submitted using the previous schema version with a Service Response of the same schema version, Users must nominate which schema version they use and all DUIS interactions will be at that schema version. Dependent on the nature of the change between versions the functionality may change but will support the previous schema version (for example a fault would not be perpetuated). 14 ENWL Question We do not agree. We expect the DCC to automatically send alerts to all users associated with a device when it becomes compromised and for the DCC to change the status held in the DCC SMI (Recovery) This will then allow Users to take the appropriate action regarding the device and address the following issues: 1) Allows the User to be aware that a device is in the Recovery process and that any existing Service Requests (including future dated?) may not be fulfilled 2) Allows the User to refrain from sending additional Service Requests to the device whilst in Recovery status 3) In the event that Recovery fails or is delayed for any reason allows the User to be aware that the device is still in Recovery Upon successful recovery we expect the DCC to: a) Send an N42 alert to confirm the new credentials that have been applied to the device b) Send an alert to confirm that recovery is complete (Recovered) c) Reset the DCC SMI to the status immediately prior to the device being placed into Recovery - we assume that changes to the SMI status are to be picked up by Users via the DCC Inventory Download/Daily Delta process and that there will not be an alert to confirm the current status as there is no existing alert which confirms status i.e. there is no alert advising a device is commissioned. We also require additional clarity on the behaviour of DCC in the following scenarios: I) The User sends a Service Request to a device which is currently in the Recovery process - what is the DCC behaviour, what error codes apply (if any)? ii) The User has existing Service Requests (On Demand or Device Future Dated) which were in process when the device was placed into Recovery iii) The User has existing Service Request (DCC Scheduled ) pending with the DCC 1 The DCC has noted concerns raised by Network Operators during recent SMKI Recovery process and DUIS/MMC consultations regarding the absence of DCC Alerts to support the SMKI Recovery Process and has concluded that the current proposed solution could be extended to incorporate the changes suggested. The DCC recommends that these changes are progressed as part of the change process and be submitted as a change candidate for inclusion in a subsequent release of the DCC systems. On this basis, the DCC is therefore not proposing to change the current design of the DCC Systems at this point of time as part of the consultation responses for the SMKI Recovery process and DUIS/MMC consultations. The design changes to support the concerns raised by Network Operators regarding the absence of DCC Alerts to support the SMKI Recovery Process will be discussed with Users separately and agreed as part of the change process. 15 ENWL Question We agree with the DCC proposed approach to maintain forward compatibility between DCC 1.2 and DCC ENWL Question We agree with the updates DCC has made to the MMC and associated schema 3 17 ENWL Question We agree. We note that DCC proposes that each DUIS and MMC Schema Version will have its own change release notes to be shared with Users alongside the revised schemas themselves. We question in what format the schema release notes will be issued? We suggest that DCC considers hosting all release notes in a dedicated SharePoint area and then provide a link in the form of an embedded URL in the schema file using a URL in <xs:annotation> and <xs:documentation> elements as this will ensure an enduring linkage between the release notes and the published schema versions. 4 We note the points made about release note formats and we will work on this over the next period and take these comments into consideration when developing the release note strategy.

3 18 ENWL Question As Electricity Distributor we have no comment on Gas functions ENWL Question We agree with the proposed approach 6 20 BG Question Yes 1 21 BG Question Yes 2 22 BG Question Yes 3 23 BG Question Yes 4 24 BG Question No Any change to support UGFR needs to have the support of EUA and from TSIRS on 14 April, EUA does not support this approach. 25 BG Question Yes for approach to re-baseline DUIS and MMC to these consultation drafts, v No to the approach for submitting any required updates post v due to further discussion, clarification and clarity required. Any release approach for MMC MUST also consider the delivery to users of the aligned version of P&C and designating MMC with any updates is useless without the delivery of the updated software release of P&C that is aligned to MMC. When MMC is designated, the associated P&C release must be available at the same time. 5 6 DCC notes the comment. This implies that a wider more detailed solution is required to resolve this issue so the DCC is minded to conclude that the proposed changes shall NOT be made at this point in time. DCC agrees with the points raised in the response and confirms that whenever the MMC schema changes there will be the need for an updated version of the Parse and Correlate software. Wider concerns for governance will be addressed by the SEC change process once DUIS and MMC are designated into the SEC. The other main comment is that the current governance arrangements are thorough but may need to change and be more flexible/reactive due to the timelines between any issue being found in DUIS, MMC and therefore Parse & Correlate and the required designation date of DUIS and MMC for DCC Live. Agree that this process should only be required in the case of a showstopper blocking issue that prevents the E2E solution (including user systems and processes and devices) from working at DCC Live and therefore should only be used in exceptional circumstances where these showstopper blocking issues in DUIS and/or MMC are identified. The try wherever possible remains as a concern/issue as whatever is agreed needs to be followed for DUIS/MMC/P&C due to the SEC Subsidiary document status and also the impact of any MMC changes on P&C which results in impact on user systems. 26 Critical Issue "all date-times specified within Service Requests by the User shall not be validated unless explicitly stated within the Service Request definitions" Exactly what does this mean? What sort of validation does this refer to? The general schema validation is referred in Table 14. DCC wish to clarify that where a date is entered by the user, no further validation beyond that of schema validation is performed by default. The individual Service Request definition will state any additional validation above and beyond the basic schema validation.

4 27 Critical Issue On Section it is specified that "Where a User wishes to cancel and not replace a future dated Service Request or Signed Pre Command, the User shall send to the DCC another Service Request of the same Service variant with an execution date time of 31/12/3000 within the Request to the same Device. " DCC accept the point made, and have changed DUIS to add full date format T00:00:00Z into text instead of the basic 31/12/3000 for increased clarity. It is true that some functionality will ignore the time portion of the date time submitted in the Service Request as pointed out in the consultation comment. On section however, Table 14, the ExecutionDateTime description was updated and now the valid value for cancellation is displayed as T00:00:00Z. Correlate interprets the "31/12/3000" date as cancellation, ignoring the "Time" component of the "Datetime. This means that, e.g., T12:43:54Z is accepted as cancellation date. Also, according with section 2.3 All references to time for the and DCC Systems shall use time with a precision to 100th of a second. so the date presented in section should be updated to " T00:00:00.00Z" 28 Critical Issue ECS68 GCS53 Timestamp xs:datetime Should be removed from the Grouping Header of the alerts. See IRP439. DCC do not accept this proposed change for this version of the DUIS and MMC. IRP439 is not part of GBCS v0.8.2 and therefore not included as part of this DUIS and MMC versions which are aligned to this baseline technical specification. This is a current issue and will be resolved by IRP439 but not in this version of DUIS and MMC. DCC agrees that the GBCS table suggests the date-time is required, however the GBCS use case templates in V0.8.2 suggests the date-time is not required. 29 Critical Issue Change from " to "xmldsig-core-schema.xsd" We believe that this change to a local file migth be unintentional. Is there a reason for this change? P&C had to change to be compliant with the schema. DCC note that this was not a change at this version (changed in May 2015). The change was intentional and was introduced to ensure that users use a local copy of the xmldsig-core-schema and avoid the need to have open internet connections to define the schema. 30 Critical Issue ECS08 The following was added to description of DayOfWeekApplicability: "Unique and numerically ordered, may not be consecutive." DCC accept the comment made and have updated the DUIS in accordance. Type sr:dayofweekapplicability is a String restricted to an enumeration. It is not numeric, so ordering is not applicable. 31 Critical Issue ECS01a BlockThreshold unit changed from kwh to Wh. Were these changes intentional? SMETS refers: Tariff Threshold Matrix [INFO] A 3 x 8 matrix capable of holding thresholds in kwh for controlling Block Tariffs. 32 Critical Issue ECS07 DebtRecoveryRatePeriod in sr:elecdebtrecovery element allows five values: HOURLY, DAILY, WEEKLY, MONTHLY and QUARTERLY. DCC can confirm that this change was intentional. This was changed directly as a response to DECC comment and aligned as part of wider Units validation work. It is noted that SMETS and GBCS differ in some unit definitions but GBCS and the protocols have been used as the master set as directed by DECC. DCC accepts the comment but do not propose to make a change to DUIS. A DCC design decision has been made to avoid further changes to the design for DCC Live. The enumeration allows for all valid values but should not use the additional values. Users should only submit either HOURLY or DAILY as per the IRP. According to SMETS (section ), due to changes introduced by IRP275, it was clarified that only HOURLY and DAILY values are valid for both ESME and GSME. So DUIS should also be updated to contemplate only these two options. GBCS v0.8.2 SMETS info also refers for DebtRecoveryRates[n]:periodNext: Period over which amountnext is to be recovered. The valid periods are hour (3600 seconds), day (86,400 seconds).

5 33 Critical Issue ECS26a DebtRecoveryRatePeriod in ra:elecdebtrecovery element allows five values: HOURLY, DAILY, WEEKLY, MONTHLY and QUARTERLY. DCC accepts the comment but do not propose to make a change to DUIS. A DCC design decision has been made to avoid further changes to the design for DCC Live. The enumeration allows for all valid values but should not use the additional values. Users should only submit either HOURLY or DAILY as per the IRP. According to SMETS (section ), due to changes introduced by IRP275, it was clarified that only HOURLY and DAILY values are valid for both ESME and GSME. So MMC should also be updated to contemplate only these two options. GBCS v0.8.2 SMETS info also refers for DebtRecoveryRates[n]:periodNext: Period over which amountnext is to be recovered. The valid periods are hour (3600 seconds), day (86,400 seconds) 34 Critical Issue ECS07 Caption for Table 114 should refer sr:elecdebtrecovery instead of sr:recoveryrateperiod DebtRecoveryRatePeriod should only allow two values: HOURLY and DAILY. See Issue above (ID 7). DCC accept the comment made and have updated the DUIS in accordance. 35 Critical Issue Caption for Table 115 should refer sr:gasdebtrecovery instead of sr:recoveryrateperiod The note on DebtRecoveryRatePeriod description is incorrect. Note that the DUIS XML Schema allows for more values but only the values listed are recognised by the GSME Schema contains only the two referred options (HOURLY, DAILY) for sr:gasdebtrecovery, so this note is note needed. DCC accept the comment made and have updated the DUIS in accordance. 36 Critical Issue Table 174 ALCSHCALCSConnectionSchedule refers that item Index (attribute of SpecialDaysApplicability) must be Unique and consecutive starting at 1. This would mean that all defined Schedules would be applicable to SpecialDay defined as 1 and so on, but that migth not be the case. DCC accept the comment made and have updated the DUIS in accordance. Probably a more accurate note should be: Unique (may not be consecutive) 37 Critical Issue ECS 47 (SR 7.5) The following note was added: Numerically ordered, not necessarily consecutive DCC accept the comment made and have updated the DUIS in accordance. No need, since this use case only allows one entry (only one index). 38 Critical Issue ECS 47 (SR 7.6) The following note was added: Numerically ordered, not necessarily consecutive DCC accept the comment made and have updated the DUIS in accordance. No need, since this use case only allows one entry (only one index). 39 Critical Issue ECS 47 (SR 7.8) The following note was added: Numerically ordered, not necessarily consecutive DCC accept the comment made and have updated the DUIS in accordance. No need, since this use case only allows one entry (only one index). 40 Critical Issue DebtRecoveryRatePeriod should only allow two values: HOURLY and DAILY. See Issue above (ID 8). DCC accepts the comment but do not propose to make a change to DUIS. A DCC design decision has been made to avoid further changes to the design for DCC Live. The enumeration allows for all valid values but should not use the additional values. Users should only submit either HOURLY or DAILY as per the IRP.

6 41 Critical Issue CS02c Response with successful status According with GBCS section : ResponsePayload ::= CHOICE { -- if the Command was successful, provide the generated Certification Request. CertificationRequest shall -- be as defined in ASN.1 by IETF RFC For reference, it is in the section headed ASN.1 Module for RFC 2986 certificationrequest CertificationRequest, -- if the Command was unsuccessful, detail the failure issuecredentialsresponsecode IssueCredentialsResponseCode } DCC have added the following descriptive text to the CertificationRequest item within the MMC: Note: CertificationRequest is only included in the response if IssueCredentialsResponseCode = success. If the command response includes CertificationRequest, the P&C software will populate the XML IssueCredentialsResponseCode with success. So if the command is a success only the "CertificationRequest" is expected to be returned, not the status. There is no value in payload to map to ResponseCode attribute in MMC StatusASN1 element. 42 Critical Issue Description for PriceScale element changed from Multiplier applied to PrimaryActiveTariffPrice to Multiplier applied to TOU/Block price values... (ECS24) and from Multiplier applied to SecondaryActiveTariffPrice to Multiplier applied to TOU/Block price values... (ECS24b). DCC confirm that the mappings shown in the consultation response are correct. DCC accept the comment regarding ECS24b and have changed the description in the MMC accordingly. We would like the confirmation that the element to be mapped changed: - ECS24 >> from (Primary)ActiveTariffPrice:scale to TariffBlockPriceMatrixTOU:valueCurrent.price_scale - ECS24b >> from SecondaryActiveTariffPrice:scale to SecondaryTariffTOUPriceMatrix:valueCurrent.price_scale And if it is confirmed the change, ECS24b description should refer only TOU prices ("Multiplier applied to TOU price values..."), since Secondary elements do not have Block prices. Currently Parse is mapping (Primary)ActiveTariffPrice:scale (ECS24) and SecondaryActiveTariffPrice:scale (ECS24b) values to respective MMC PriceScale elements. 43 Critical Issue The following text was removed from TariffThresholds element: Multiplier and divisor applied as defined in GBCS. Was this removal intentional? DCC accept the comment. The change was intentional but after further review the change has been reversed and the descriptive text re-instated. No change will be made to P&C software. Parse is calculating TariffThresholds values using multiplier("block Period: ThresholdMultiplier") and divisor("block Period: ThresholdDivisor") present in ZigBee response, as referred in ZSE documentation: D ThresholdMultiplier Attribute: ThresholdMultiplier provides a value to be multiplied against Threshold attributes. If present, this attribute must be applied to all Block Threshold values... This attribute must be used in conjunction with the ThresholdDivisor attribute. 44 Critical Issue Possible inconsistency with SMETS: Description text and Units for LowMediumPowerThreshold and MediumHighPowerThreshold refer W, but SMETS ( and ) refers: A value in kw defining the threshold between an indicative Critical Issue Possible inconsistency with SMETS: Description text and Units for LowMediumPowerThreshold and MediumHighPowerThreshold refer W, but SMETS ( and ) refers: A value in kw defining the threshold between an indicative SPEN Question Yes 1 47 SPEN Question Yes. SPEN's DCC Gateway provider (Siemens/Omnetric) will provide further detail as necessary SPEN Question Yes. SPEN's DCC Gateway provider (Siemens/Omnetric) will provide further detail as necessary. 3 DCC note the comment but do not propose to change the DUIS or MMC. The units value is aligned with GBCS. DCC note the comment but do not propose to change the DUIS or MMC. The units value is aligned with GBCS.

7 49 SPEN Question Yes. SPEN's DCC Gateway provider (Siemens/Omnetric) will provide further detail as necessary SPEN Question N/A 5 51 SPEN Question Yes. SPEN's DCC Gateway provider (Siemens/Omnetric) will provide further detail as necessary UKPN Question We do not agree with updating the schema prior to Go Live without some form of backwards compatibility to version Our issues and rationale are described in our answer to question 2. In addition to our concerns about the timing of this release, where meters have an SMI status of "Recovery", messages to those meters will be blocked. However, parties who are not the responsible Supplier (or the Party invoking the Recovery Procedure) will not be aware that the meter state has changed, as there is no alert. Therefore, it is likely that a number of parties will suddenly find that communication to many thousands of meters is blocked for no obvious reason, leading to costly time and effort to determine the reason for the block. We propose that an error message or alert is used to inform all registered parties that the meter state has changed. 1 The DCC has noted concerns raised by Network Operators during recent SMKI Recovery process and DUIS/MMC consultations regarding the absence of DCC Alerts to support the SMKI Recovery Process and has concluded that the current proposed solution could be extended to incorporate the changes suggested. The DCC recommends that these changes are progressed as part of the change process and be submitted as a change candidate for inclusion in a subsequent release of the DCC systems. On this basis, the DCC is therefore not proposing to change the current design of the DCC Systems at this point of time as part of the consultation responses for the SMKI Recovery process and DUIS/MMC consultations. The design changes to support the concerns raised by Network Operators regarding the absence of DCC Alerts to support the SMKI Recovery Process will be discussed with Users separately and agreed as part of the change process. 53 UKPN Question Given the time frame and RAG status for Industry Testing, and the complexity of getting all parties to interoperate from day 1, we believe that the timing of this change creates unacceptable additional risks to the programme and to DCC Users. Where new elements are introduced to the schema, User Systems will need to do more than just parse the XML - they will also need to store the data and modify business processes. The time frame for implementing the change into the User Gateway product, functionally testing it, installing and testing the product at client site and testing the installation is significant. Introducing further change into 1.2 in order to protect a design assumption may create more issues than allowing an exception to the design assumption and providing backwards compatibility for all Users to v0.8.2 of the schema. 2 DCC notes the concerns raised and the potential risk noted, but the only other option is to not include the additional functionality and release an updated schema for the R1.3 that causes different risks and increased effort on all parties. The DCC does not consider this to be appropriate and most other respondents agree with the DCC proposed position. DCC is therefore not expecting to change its proposed approach. Our proposal is that DCC provides backwards compatibility to v0.8.2 of the schema to allow all s to minimise and control the risks to their own programmes by allowing users to absorb change at a rate which is appropriate to their programmes, timelines and resource pools. 54 UKPN Question Yes, we agree with these updates UKPN Question Yes, we agree with and support the proposed versioning approach UKPN Question This command is not relevant to an electricity distributor and as such we have no comments. 5

8 57 UKPN Question We do not agree with updating the schema prior to Go Live without some form of backwards compatibility to version Our issues and rationale are described in our answer to question 2. 6 DCC is committed to supporting one previous version of the DUIS defined interface (and related DUIS/MMC schema) following a planned incremental release. The interface will respond to a Service Request submitted using the previous schema version with a Service Response of the same schema version, Users must nominate which schema version they use and all DUIS interactions will be at that schema version. Dependent on the nature of the change between versions the functionality may change but will support the previous schema version (for example a fault would not be perpetuated). 58 npower Question Yes we agree with the updates, however we have discovered a number of small issues: In Section Data Validation, we are unclear what the scenario would be for the receipt of an E50. The Process description isn't clear. In Section the units for DebtRecoveryRateCap are specified as ECB, why not EUR? This also wasn't mentioned as a change in the commentary document. Typo: Section Additional DCC System Processing - the new addition of 'or Gas Supplier' should be 'or Gas Supplier' 1 DCC notes the positive response to DCC's recommended approach. Regarding the individual issues raised: 1. The E50 is returned when the user has sent a request for a Command for Local Delivery and the users Service Requests are being quarantened (see TADP). 2. This is no change to the enumeration which refers to 'ECB' where the currency is Euro. 3. The typo has been corrected in the post-consultation version of the DUIS. 59 npower Question Yes we agree with the approach for changing DUIS to support the SMKI Recovery Procedure npower Question Yes we agree with the updates, however we have discovered a number of small issues: In Section the PrimaryActiveTariffPrice attribute has units of GBP/Euro per m3 when it should be per kwh as the description implies. In Section the PrimaryActiveTariffPriceScale description is unclear. We would like it clarified how this scalar value is used. Changing the formatting in the XSD by adding Line breaks etc makes it difficult to compare from previous version. 61 npower Question Yes we welcome the new versioning approach. However we would also like to see a formalised approach to filenames for the XSD's in the DUIS and MMC documents. 62 npower Question No. Whilst we welcome the changes to make the UncontrolledGasFlowRate data item usable, we feel the DCC should leave the units to m3 per hour and send this to the meter as m3 per hour with the addition of a scaling factor to bring the effective value down to litres per hour. Subject to confirmation from meter manufacturers that this can be accommodated for go-live. 63 npower Question Partially, we broadly support the approach to re-baselining. We would like to call out the impacts that this may have in the test space especially if Parse & Correlate is delayed. We also require clarity on the approach that will be followed for 1.2 UEPT planned to start 13th June, i.e. is the expectation to start testing on the current version (0.8.2) and then upgrade to No, we don't support the approach to subsequent versions of the documents. We welcome the DCC approach to user are involved in the decision making process and what we understand the intent of the proposed approach. However we have a number of concerns: * that this may result in a deluge of new versions that could appear at any stage during testing. * Impact on P&C delivery as a result of MMC changes * impact on P&C delivery as a result of GBCS changes * process needs defining without the ability to deviate - so an agile process needs defining and sticking to. Therefore, we would like to see a more regimented approach to releases of DUIS and MMC. Perhaps, given the time scales involved, we should plan for only one new version of DUIS and MMC (and hence P&C). In this way we can all plan for change in a more effective manner. 64 EUK Question Yes, we agree with the updates, pending resolution of the clarification points captured in the tab ''Q1 Supplementary Comments'' DCC notes the positive response to DCC's recommended approach. Regarding the individual issues raised: 1. The units value is correct - the description refers to the calorific conversion being needed to relate the price to the tariff. 2. The scaler is 10^n (10 to the power of n), so a scaler value of 3 would be price x 10^3... equal to... price x DCC notes the comment on changing formatting in the XSD and will endevour to avoid undure formatting change in future. DCC notes the positive response to DCC's recommended approach. We note the points made about XSD filenames and will consider these. DCC note the comments and the response implies wider changes than the simple documentation update proposed. A wider more detailed solution is required to resolve this issue so the DCC has concluded that the proposed changes will not be made at this point in time. DCC notes the supportive general comment. DCC wish to minimise the impact of further changes or releases on testing phases. There is no intention to introduce releases or changes to DUIS and MMC beyond those that are planned and published. DCC recognise and fully support several respondents comments that any release approach for MMC must also consider the delivery to users of the aligned version of P&C and designating MMC with any updates is insufficient without the delivery of the updated software release of P&C that is aligned to MMC. DCC confirm that any change to the MMC XML schema will result in an updated version of the Parse and Correlate software being made available to Users. DCC notes the positive overall response. Additional responses are provided separately regarding the detailed queries.

9 65 EUK Question Yes, we agree with the recommended approach. However, we seek clarification / confirmation where a device is at a status of Recovery and the device is switched to a new supplier, the CoS process will effectively recover the device without the new supplier needing to issue SR DCC notes the overall positive response regarding DCC's recommended approach A Device must complete the SMKI Recovery Process before any change of supplier (replacement of security credentials) can occur on a device, as when a device is in a status of Recovery any communication to that device is not possible and is prevented as defined by the SMKI Recovery Process. The CoS Party processing within the DCC solution will NOT recover a Device as part of its standard processing and is not designed to do so. CoS and Recovery are two separate processes that must complete individually in their own right. 66 EUK Question Yes, we agree with the updates, pending resolution of the clarification points captured in the tab ''Q3 Supplementary Comments''. 67 EUK Question Yes, we agree with the proposed versioning approach and support its implementation. However, we have some clarification points to raise: 1/ Whilst we support the non-standard management of the schema versions in the short term to optimise on the resolution of issues during test, DCC needs to ensure subsequent versions of the P&C software are released at the same time as any amendments, to ensure its users are able to test changes in a timely fashion. 2/ Whilst we support the DCC's long term view to introduce a more robust versioning approach through the "schemaversion" element. It is not clear how the 2 schemaversion values are intended to be managed prior and post go-live, further explanation would be helpful here. 3/ Additionally, we have the following specific comments on the schema: a) The version details in the schema comment has a different filename to the file issued with the consultation e.g. Mmc_xml_schema_v xml and comment states MMC Schema Draft xsd. b) Schema comment states aligned with GBCS v0.8.2 but we understood this is GBCS v0.8.2 plus the CRPs/IRPs included for DCC release 1.2 and 1.3? c) Date stated as 26th February not aligned with consultation date. We assume this includes all changes identified in consultation. 68 EUK Question There is broad agreement and recognition that the UncontrolledGasFlowRate data item needs to be updated to be more usable / granular and we welcome the changes DCC is proposing to make. However, it is important to note the discussions from the DECC TSIRS meeting in April: 1/ EUA rejected the current approach as documented by DECC in CRP449 (presented at the TSIRS meeting) - this needs EUA's input via TSIRS to move this forward. 2/ Meter manufacturers' view was that the Zigbee units value should be consistently used in cubic meters per hour and a more suitable solution is to amend the hard coded value to support the required accuracy (i.e. changing hard coded value from 1 to 7). If this option is not supported then whilst the GBCS CRP449 does provide a short term fix with no systems impact to the DCC, manufacturers and suppliers' asset test teams have advised the CRP will have an impact in terms of getting assets aligned and retested. One option originally proposed by EUA was the unit of measure should remain as m3 per hour and that this should be sent to the meter as m3 per hour with the addition of a scaling factor to bring the effective value down to litres per hour. Subject to confirmation from EUA / meter manufacturers that this can be accommodated for DCC Live. 3/ The current m3 per hour (equivalent 1000 litres per hour) is very high. The data type is unsignedshort which currently gives a range of 1m3 per hour to m3 per hour, the upper value which is not possible in a domestic gas installation. Introduction of a scalar gives a range of m3 per hour to m3 per hour and gives a much better degree of control over gas flow measurement. The maximum is still well above what is possible in a domestic gas installation DCC notes the positive overall response. Additional responses are provided separately regarding the detailed queries. DCC notes the overall positive response regarding DCC's proposed approach 1. DCC agree that any subsequent versions of MMC schema will be issued at the same time as the Parse and Correlate Software. 2. DCC agree that the use of the schemaversion item needs further clarification in the context of the first change that invokes its use. This is likely to be as a result of the SEC Mod process. 3.a - DCC accept there is a disparity, the key point being that the version MMC schema is aligned. 3.b - To confirm DUIS and MMC schemas are up to date with GBCS v0.8.2 and NOT any CRPs or IRPs. 3.c - The date is the development date and it is not meant to align with the consultation date as development of schemas and consultation are not on the same timeline. It does contain all changes as detailed in the consultation. DCC note the comments and the response implies wider changes than the simple documentation update proposed. A wider more detailed solution is required to resolve this issue so the DCC has concluded that the proposed changes will not be made at this point in time.

10 69 EUK Question We broadly support the DCC's recommended approach for the re-baselining of DUIS and MMC. However, we do not agree with the DCC's recommended approach for the submission of any required updates post v Whilst we welcome the DCC approach to user engagement within the decision making process and what we understand the intent of the proposed approach, we have a number of specific points to raise: 6 DCC notes the supportive general comment. DCC wish to minimise the impact of further changes or releases on testing phases. There is no intention to introduce releases or changes to DUIS and MMC beyond those that are planned and published. * Impact on Parse and Correlate delivery as a result of MMC changes and GBCS changes: the DUIS/MMC consultation will result in a new release of the P&C software by DCC, delivered at the end of May, there is a risk that that this will not allow sufficient time for DCC to integrate and test the new software in their development systems and roll it out to affected suppliers before the start of UEPT. If the new version is not available to and tested by those suppliers on 13 June, this would effectively mean the Suppliers would not be ready to run all UEPT Common Test Scenarios, and therefore not ready to undertake UIT at the designated time - would this be a breach of the SEC obligation? * Process needs defining without the ability to deviate - an agile process needs defining and sticking to. Therefore, we would like to see a more regimented approach to releases of DUIS and MMC. * It is unclear whether there will be a deluge of new versions that could appear at any stage during testing - it is unclear how the defect / issue resolution process is aligned to a robust and regimented approach to releases of DUIS / MMC. DCC should plan to issue the P&C software where impacted in line with the schema and DUIS and MMC document set. * Inclusion of these changes in DCC release 1.2 will have an impact on suppliers' release. However non-inclusion may result in the changes being deferred to release 2 which would create a significant misalignment with SMETS2 assets which cater for these changes. Hence we believe DCC 1.2 release should include the changes provided through this consultation though we are concerned there will be an impact on suppliers' releases. * Consultation states this is the process "DCC will try to follow.." - a more certain management of the process is essential to enable its users to plan for change during a very challenging testing timeline. * DCC in conjunction with industry (s / Suppliers) should establish the priority of the various services and processes required by the supplier which need to be supported for DCC Live and agree a plan to ensure these areas are prioritised in terms of fixes. s should be consulted at the earliest point on the relative priority of resolution of issues. * A more formal review process is required (planned weekly) but with the support to increase frequency where required or when an excessive level of issues are identified. This needs to be robustly co-ordinated with the testing process / governance. DCC recognise and fully support several respondents comments that any release approach for MMC must also consider the delivery to users of the aligned version of P&C and designating MMC with any updates is insufficient without the delivery of the updated software release of P&C that is aligned to MMC. DCC confirm that any change to the MMC XML schema will result in an updated version of the Parse and Correlate software being made available to Users. 70 EUK Issue Section 2.3 has text added which states Date / Time fields are not validated unless specified with the SR - we assume standard XML date / time formatting validation is always applied - please confirm and add statement to clarify. DCC can confirm that the standard date/time schema validation is applied to all dates entered in SRs. Additional validation may be applied at the individual SR level and this will be defined in the individual SR sections of DUIS. 71 EUK Issue Legal drafting of last paragraph of section 2.5 is very confusing as it is not clear if device alerts from meter equipment passed through the CHF are passed on by DCC based on the changes:- "The DCC shall send Responses, alerts generated in the DCC Systems (or any Alert generated by a Communications Hub Function) and Alerts to the relevant User as Service Responses, DCC Alerts and Device Alerts." DCC notes the comment. The wording of DUIS and the MMC has been reviewed by DECC's legal team. The DCC have reviewed this paragraph but do not propose to make further change at this time. 72 EUK Issue There is no 3.1, it jumps from 3 to EUK Issue p45 has the following text "Note that where a Device has a SMI Status" should this not be "an SMI" - since the S in the acronym starts with a vowel sound. 74 EUK Issue Data Validation, we are unclear what the scenario would be for the receipt of an E50. The Process description is not clear. We suggest that this should make clear that you get the alert if the SR for local command delivery has been quarantined - i.e. remove the double negative. DCC agrees with the comment and has updated the DUIS accordingly DCC agrees with the comment and has updated the DUIS accordingly DCC notes the comment. The intent here is that the return of a Command for local deliver is a synchronous web service response and as such if a SR is quarantined by Anomaly detection there is no response so the web service would not complete. This is why E50 Response Code has been created so that a synchronous web service response is possible and the User receives the E50 as a response indicating that the SR has been quarantined.

11 75 EUK Issue p88 N44 / N45 - alert names are illogical - would be better tagged as recovery / recovered as per the description provided in the consultation DCC notes the comment. The description defines what the Alerts perform, but DCC do not propose to change the identifiers. These are different alerts depending on the outcome of the recovery completed and one is a specialisation of the other. DCC Alert N44 informs the recipient that the Recovery is complete and that ACB credentials have been successfully placed on the device to complete the recovery process. A further process must be completed by the supplier to change ACB certificates to correct non ACB certificates at a later date. (SR6.21) DCC Alert N45 informs the recipient that the Recovery is complete and that the credentials have been successfully placed on the device to complete the recovery process which are the final credentials and NOT ACB credentials. 76 EUK Issue The units for DebtRecoveryRateCap are specified as ECB, why not EUR? This also was not mentioned as a change in the commentary document. The Units in DUIS have always stated as GBP/EUROs but enumerated values are ECB for Euros. This has not changed in this version. Previously the units value was not specific about which units were being applied as it simply said 100th pence which is incorrect if in Euro mode. This change was to clarify in line with all other Unit values defined. DCC have not changed the DUIS in resonse to this comment. 77 EUK Issue "UncontrolledGasFlowrate" still shown as 'm3/hour' not 'litres/hour' - this is obviously subject to a consultation question DCC agrees with the respondents comment - as stated in the consultation document, the changes proposed for "UncontrolledGasFlowrate" have not been made to the document and they would only be made if the consultation concludes that change is required. The DCC has concluded as part of this consultation that a change in this area is not appropriate as it is not supported by all parties and so there will NOT be a change to the unit values and the DUIS and MMC document will remain unchanged. 78 EUK Issue Typo: 'Securirty Credentails' should be 'Security Credentials' 79 EUK Issue Typo: additional DCC System Processing - the new addition of 'or Gas Suplier' should be 'or Gas Supplier' 80 EUK Issue Typo - double word (version) "This should align with the SMETS_CHTS version version_number value contained on the CPL" 81 EUK Issue Device Firmware Version data type redefined as binary 4 octets (8 chars) which is inconsistent with GBCS and CPL definitions (4 hexadecimal octets - 8 chars) - the word binary that has been added is confusing and this should be replaced by hexadecimal. DCC agrees with the comment and has updated the DUIS accordingly DCC agrees with the comment and has updated the DUIS accordingly DCC note that this is a data attribute of a version and version_number is a data item in its own right so DCC do not propose to change the DUIS in response to this comment. DCC agrees with the comment and has updated the DUIS accordingly, note that there were several occurances. 82 EUK Issue p326 DeviceManufacturer usefully aligned with GBCS and CPL - can we extend the definition of the values to specify as per the Zigbee standard manufacturer codes which we understand are 2 hex octets The DCC solution can only align with the CPL which is the DCC input. The DCC and the DUIS cannot align with other records outside of our control. ZigBee values can be used within these definitions so this does not impact functionality delivered by the solution. DCC would suggest that this comment should be made against the CPL to confirm which value is populate onto the CPL. 83 EUK Issue p326 DeviceManufacturer states "For IHD and CAD this data item is free text" will be a problem for IHD when it is included in CPL as part of the firmware upgrade changes - be useful to limit IHD to 2 hex octets. This comment relates to a SEC Modification proposal and therefore is not relevant for this consultation based on the current SEC version. DCC do not propose a change in response to this comment. If the SEC Modification is approved the DUIS may require subsequent change. 84 EUK Issue p326 DeviceModel states "For IHD and CAD this data item is free text" will be a problem for IHD when it is included in CPL as part of the firmware upgrade changes - be useful to limit IHD to 4 hex octets. Note typo at end of description. - also typo for SMETS_CHTS_VERSION - version repeated in description This comment relates to a SEC Modification proposal and therefore is not relevant for this consultation based on the current SEC version. DCC do not propose a change in response to this comment. If the SEC Modification is approved the DUIS may require subsequent change.

12 85 EUK Issue p326 firmware version states "The binary value shall be four octets in length" - we assume this is wrong as it is hex everywhere else and will not support CPL if limited to binary. 86 EUK Issue Use 'or' not 'of' in "A User must send one Service Request per Device to add of remove from the" 87 EUK Issue p351 specifies Installation Credentials as "Binary length 16 (octets) equating to 32 characters" - is this correct or should it be a hex value? 88 EUK Issue Table 252 p399 recovery complete - typo - wrong alert code - should it be N45? 89 EUK Issue Figure 1 page 11 - schema diagram deleted and replaced with new diagram which looks the same - please explain what the changes are - we assume the cardinality has been corrected as requested from infinity to 100? Are there any other changes besides this? 90 EUK Issue The PrimaryActiveTariffPrice attribte has units of GBP/Euro per m3 when it should be per kwh as the description implies. 91 EUK Issue The PrimaryActiveTariffPriceScale description is unclear. We would like it clarified how this scalar value is used. 92 EUK Issue This includes PrimaryActiveTariffPrice and scale but they are not available through SR please explain as it seems illogical we can read but cannot set. DCC agrees with the comment and has updated the DUIS accordingly, note that there were several occurances. DCC agrees with the comment and has updated the DUIS accordingly DCC agrees with the comment and has updated the DUIS accordingly DCC agrees with the comment and has updated the DUIS accordingly The cardinality was the only change made to this diagram as suggested. The units are as specified by DECC as part of our last alignment with GBCS. DCC do not propose any change to DUIS in response to this comment. DCC believes that this description is clear and aligned to GBCS. DCC do not propose any change in relation to this comment. The SR 'UpdatePrice(Primary Element)' provides for setting the price in block/tou tariffs prior to the calorific conversion, there is no value equivalent to PrimaryActiveTariffPrice. The 'ReadTariff(PrimaryElement)' returns the Block and TOU tariffs and also the PrimaryActiveTariffPrice which is prior to calorific conversion. 93 EUK Issue MMC SR provides manufacturer as char 32 which is incorrect (specified as char 30 SR 8.4) - last response from DCC on this previously raised comment stated that DCC would correct in new version of the schema. DCC do not propose a change in this definition, this issue has been discussed in previous consultations also. There is a mismatch but as the input is 30 and the output is 32 this would not be a system problem. DCC will add it to the forward change log to consider as a later change but this will need changes to other specifications as well that the DCC cannot control. There could also be potential system changes so DCC do not see it as worthwhile to propose this change at this point. 94 EUK Issue Changing the formatting in the XSD by adding Line Breaks etc makes it difficult to compare from previous version. DCC notes the comment and we will aim to minimise changes to formatting within the schema in future. 95 EDF Question EDF Energy supports the changes to DUIS and its schema pending successful resolution of the points which are detailed in "Q1 - DUIS" tab. 96 EDF Question Yes, EDF Energy supports DCC's recommended approach. As this change has come to the baseline late it is worth noting EDF Energy will not have an automated solution to support SMKI recovery in the short term. However our understanding is the change would enable the recovery to be managed manually by EDF Energy - please confirm? As stated in the consultation releasing the changes for SMKI Recovery in release 1.2 will avoid unnecessary schema and therefore system changes between 1.2 and 1.3 which will be a very challenging schedule. Please confirm where a device is at a status of Recovery and the device is switched to a new supplier the CoS process will effectively recover the device without the new supplier needing to issue a 6.21? 1 2 DCC notes the positive overall response. Additional responses are provided separately regarding the detailed queries. DCC notes the overall positive response to DCC's recommended approach DCC can not confirm a parties implementation choices for manual or automated options. A Device must complete the SMKI Recovery Process before any change of supplier (replacement of security credentials) can occur on a device, as when a device is in a status of Recovery any communication to that device is not possible and is prevented as defined by the SMKI Recovery Process. The CoS Party processing within the DCC solution will NOT recover a Device as part of its standard processing and is not designed to do so. CoS and Recovery are two separate processes that must complete individually in their own right.