Error Handling Strategy

Size: px

Start display at page:

Download "Error Handling Strategy"

Megan Fowler
6 years ago
Views:

1 Error Handling Strategy Author: DCC Operational Policy Draft Version 1 Date: 1 st May 2014 Page 1 of 13

2 Contents 1. Document History Document Location Review Dates Revision History 3 2. Introduction Purpose Scope 4 3. Overview Definition of an Error Processing Overview Error Handling and Retry Principles Retry principles Modes of Operation Error Handling and Retry Incorrect Response Code Received Availability Incident Management Reporting and Service Measures Definitions 11 Page 2 of 13

3 1. Document History 1.1 Document Location The source of this printed document can be found on DCC Sharepoint. 1.2 Review Dates Date of this Revision 1 st May 2014 Annually 1.3 Revision History Date of Next Review Revision Date Revision Number Changed By Summary of Changes 27 th February Nicola Robertson Initial Draft 21 st March Nicola Robertson Updates post Service User Forum 25 th March Nicola Robertson Updates after peer review 31 st March Nicola Robertson Updates post Service User Forum 4 th April Nicola Robertson Updates post initial feedback 14 th April Nicola Robertson Updates post feedback 28 th April Nicola Robertson Updates post User feedback 29 th April Nicola Robertson Updates post User feedback 1 st May Nicola Robertson Updates post feedback Page 3 of 13

4 2. Introduction 2.1 Purpose The purpose of this document is to describe the Error Handling Strategy which is to be adhered to by DCC and Users. This document defines how to determine and classify instances, within the DCC Total Systems, where a Service Request or the commands or responses related to it fail to provide the result expected from that type or category of Service Request, and sets out procedures to be followed and actions to be taken for the purposes of investigating and correcting such failures. This document also provides the principles of Error Handling and Retry which are to be applied for Service Request/Response processing on the DCC User Gateway Interface and SMWAN Gateway Interface. 2.2 Scope This document is only concerned with Service Request/Response processing on the DCC User Gateway operation and onward transmission, responses and alerts generated by Type 1 devices and Elective Services. Error Handling on other interfaces is covered by individual Interface Specifications for those interfaces. This document is intended to articulate the intended behaviours under the full range of error conditions, and defines a predictable outcome for each error condition for the User. Outage and Restoration Notifications are out of scope of this document. Any issues arising with the service or process will be managed by the Incident Management Policy. Page 4 of 13

5 3. Overview 3.1 Definition of an Error An Error is an unexpected condition in the DCC Total Systems specifically as a result of raising, executing or transmitting a Service Request, Service Response or alert. Errors apply to User Gateway operation and onward transmission. A Service Request is a request for one of the Services listed in the DCC User Gateway Services Schedule (or, in the case of Elective Communication Services, provided for in the relevant Bilateral Agreement). 3.2 Processing Overview The basic principles for Service Request processing involve a User constructing a Service Request in the format described in the DCC User Gateway Interface Specification (DUGIS) and sending it to the DCC. Non-Critical Service Requests shall be transformed to GB Companion Specification (GBCS) format and sent to the relevant Device. Critical Service Requests, the transformation to GBCS Format shall be carried out and the transformed request (a Pre-Command) shall be returned to the User who shall check and sign. The signed Pre-Command shall then be returned to the DCC who shall then send it to the relevant Device. In both cases, a Service Response in GBCS Format shall be sent by the Device to the DCC and the DCC shall forward this response to the relevant User. Similarly, unsolicited Alerts in GBCS Format shall be sent by the Device to the DCC and the DCC shall forward the Alert to the relevant User. There are variations on this basic processing pattern which are described in more detail in the DCC User Gateway Interface Specification. Page 5 of 13

6 Figure 1 Basic Service Request Processing 3.3 Error Handling and Retry Principles The approach to Error Handling and Retry within the DCC Total Systems follows four main principles, Acknowledgement, Retry, Notification and Fulfilment Responsibilities: Principle Acknowledgement Retry Notification Fulfilment Responsibilities Outcome Where data is passed across an interface between two parties, there will be an Acknowledgement to indicate that responsibility has passed from one party to another Positive Acknowledgements indicate to the sending party that the transfer was successful Negative Acknowledgements indicate to the sending party that the transfer was unsuccessful Where an error has occurred the DCC Total Systems shall reattempt to process / transfer the data a set number of times before failing The Retry process is necessary to attempt to fulfil the original action within the Service Level Agreement times, and acknowledges that failures can occur as the data is passed between parties In all cases where the DCC Total System is called on by another party to perform a task, the DCC Total Systems shall inform the caller of the final status of that task, whether it was successful or not. Each interface specification shall clearly state whose responsibility it is to reprocess / resend data, and what the expected outcomes will be Page 6 of 13

3.4 Retry principles For Retry and timeout behaviour the following principles are applied: Components shall perform one or more retries before the SLA limit Components can also carry out a further

7 3.4 Retry principles For Retry and timeout behaviour the following principles are applied: Components shall perform one or more retries before the SLA limit Components can also carry out a further Retry beyond the SLA limit if this is likely to give an increased chance of success (whilst not being beyond the reasonable expectation of the User), this shall not stop an incident being raised within the Service Management System Retry and timeout behaviour for components at a lower layer of the processing stack shall be within the duration of Retry and timeout behaviour of components at higher layers of the processing stack (i.e. a higher level component shall not time out before a lower layer has completed its Retry behaviour). Layers of the processing stack correspond to the different stages in the path of the message flow. 3.5 Modes of Operation There are a number of variations on the basic Service Request processing described above. There are some variations for Requests, Responses and Alerts that only require interaction with the DCC Total Systems and have no interaction with Devices. There are also variations in processing of Requests and Responses to/from Devices based on the scheduling requirements of when a Request needs to be executed. Figure 2 below shows the variations as Modes of Operation, in relation to communication between the User, the DCC and the Device. Figure 2 Modes of Operation A description of each of these modes of operation is provided in the DCC User Gateway Interface Specification. 3.6 Error Handling and Retry Errors can be caused by an incomplete or invalid Request, due to a failure to deliver the message to the Device, or failures to process a request within the DCC Total System. The Response Code contained in the Service Request Response message shall indicate the failure type. Page 7 of 13

8 Errors that are encountered when processing a Request, which cannot be resolved by the Retry strategy, shall be notified to the original User who requested the service. This section describes the Error Handling and Retry strategy for each mode of operation as described in the DUGIS. Further detail and associated Response Codes are detailed in DUGIS. Error Scenario Mode of Operation Approach DCC Service unavailable Invalid request or Access Control failure Transform, DCC Only, On Demand, Future Dated Transform, DCC Only, On Demand, Future Dated, DCC Scheduled The User shall Retry as appropriate for their business process and SLA If the DCC Services are persistently unavailable the User shall raise an Incident with DCC having first checked for known issues via the Self-Service Interface The User shall first ensure connectivity to the DCC and then make a decision on what to do next based on the response received Failure to send command over SMWAN On Demand The DCC shall Retry at least once within SLA If still failed after the defined period a DCC Alert with the appropriate Response Code shall be sent to the requesting User Failure to receive response over SMWAN On Demand The DCC shall Retry at least once within SLA If nothing is received after the defined period the Service Request shall be marked as failed and the DCC Service Response shall be returned with appropriate Response Code to the requesting User The User has an obligation to handle missing responses for On Demand Service Requests Unable to deliver response to User On Demand, Future Dated, DCC Scheduled, Meter Scheduled, Device Alerts, DCC Alerts The DCC shall Retry at regular intervals If still failed after the defined period the request shall be placed on the failed queue for re-delivery once the User connectivity is restored Failed responses shall be held for a defined period for resending once User connectivity is restored If the User fails to receive expected Service Responses / Alerts then the User shall raise a DCC Incident having first checked for known issues via the Self-Service Interface If the DCC is unable to deliver data to the User, then the DCC shall raise a DCC Incident and can inform the user in line with the interface specification. Page 8 of 13

9 Error Scenario Mode of Operation Approach Failure to send command over SMWAN Future Dated, DSP Scheduled DCC shall Retry at least once within initial Retry period (as defined). If still failed after the defined period the request shall be placed on the redelivery queue for subsequent re-send after the defined period. If still failed after the defined period a DCC Alert with the appropriate Response Code shall be sent to the requesting User Failure to receive response over SMWAN Future Dated, DSP Scheduled DCC shall Retry at least once within the initial Retry period If nothing has been received after the defined period the request shall be placed on the redelivery queue for subsequent re-send after the defined period. The Retry process shall continue for the defined period from the time at which the Service Request was received No response received from Smart Metering Device Meter Scheduled Future Dated User fails to receive response from DCC at scheduled time If no response is received from the specified Smart Metering Device within the defined period of the execution date and time contained within the original Service Request then DCC shall return a DCC Alert to the Service User with a Timeout Response Code The User shall first ensure connectivity to the DCC and then make a decision on what to do next based on the response received Unknown Invalid message The User shall raise an Incident with DCC having first checked for known issues via the Self-Service Interface 3.7 Incorrect Response Code Received If a User receives a Response Code that does not correlate to the Service Request type they shall raise an Incident with the DCC for investigation. If the DCC receive a Response Code that does not correlate to the Service Request type an Incident shall be raised by the DCC in the DCC Service Management System. 3.8 Availability In the event that a User has a known outage that will affect the operations within this document they shall notify the DCC to enable them to act appropriately. Once service has been restored they shall inform the DCC. In the event that the DCC has a known outage that will affect the operations within this document they shall notify Users via the Self Service Interface. Page 9 of 13

10 Once service has been restored they shall update the notice on the Self Service Interface. 3.9 Incident Management All Incidents raised as a result of a failed Service Request that meet the criteria as detailed in this document shall be raised and handled in accordance with the Incident Management Policy Reporting and Service Measures The Incident Log shall feed into the standard service management reporting process, Metrics shall be made available via that process. Trend Analysis shall be performed on the available data and the output shall feed to the Problem Management process. Page 10 of 13

11 4. Definitions Term Acknowledgement Critical Service Request DCC User Gateway DCC User Gateway Interface DCC User Gateway Interface Specification / DUGIS Device Elective Communication Service Error Handling Fulfilment Responsibilities GB Companion Specification / GBCS GBCS Format Definition Means, in respect of any Service Request or Signed Pre-Command sent by a User to the DCC, a communication by the DCC to the User via the DCC User Gateway acknowledging receipt of the User s communication Means a Service Request which is identified as critical in the DCC User Gateway Services Schedule Interface Specification (or, in the case of Elective Communication Services, the relevant Bilateral Agreement). Means the communications interface designed to allow the communications referred to in Section H3 (DCC User Gateway) to be sent between the User and the DCC. Means the communications interface designed to allow the communications referred to in Section H3 (DCC User Gateway) to be sent between the User and the DCC. Means the SEC Subsidiary Document of that name set out in Appendix [TBC]. One of the following: (a) an Electricity Smart Meter; (b) a Gas Smart Meter; (c) a Communications Hub Function; (d) a Gas Proxy Function; (e) a Pre-Payment Interface; (f) an Auxiliary Load Control; or (g) any Type 2 Device (e.g. IHD). Means the provision of communication services that are (or are to be) defined in a Bilateral Agreement (rather than the DCC User Gateway Services Schedule) in a manner that involves communication via the SM WAN (provided that such services must relate solely to the Supply of Energy or its use). The management of errors through the Smart Metering System The responsibility on the DCC to fulfil Service Requests raised via the User Gateway Means the specifications set out as a SEC Subsidiary Document in Appendix [TBC]. Message format as per GBCS Page 11 of 13

12 Incident Incident Management Metrics (Incident) Non Critical Service Request Outage Notification Problem Management Response Code (Error Handling) Restoration Notifications Retry SEC Service Request Service Response SLA Smart Metering Device Means an event which causes (or may cause) an interruption to (or a reduction in the quality or security of) the Services, as further described in the Incident Management Policy (excluding Incidents that are subject to the Registration Data Incident Management Policy, but not excluding interruptions to the Services that are consequent on such Incidents). Means a framework of processes designed to identify, raise, allocate responsibility for, track and close Incidents. Metrics define what is to be measured and reported to help manage a process or service. Means a Service Request which is not identified as critical in the DCC User Gateway Services Schedule (or, in the case of Elective Communication Services, the relevant Bilateral Agreement). Notification of temporary suspension of operation The process that undertakes the management of Problem investigation and resolution related activities, both reactively and proactively. Standard response to a message receipt Notification of resumption of operation Further attempts at processing data Smart Energy Code Means a request for one of the Services listed in the DCC User Gateway Services Schedule (or, in the case of Elective Communication Services, provided for in the relevant Bilateral Agreement). Means, in respect of a Service Request sent by a User, one or more communications in response to that Service Request, either (as the context requires) from a Device to the DCC, or from the DCC to the User Service Level Agreement. This is the agreed definition of how all service components should be delivered, including timescales, service quality and availability. Means either an Electricity Smart Meter or a Gas Smart Meter (as the context requires). Page 12 of 13

13 SMWAN Gateway Interface Trend Analysis This is the Smart Meter Wide Area Network Gateway Interface through which all Smart Meters are connected into the DCC service. An activity undertaken by Problem Management whereby information relating to the resolution of multiple similar Incidents is analysed to identify common traits in order to help with identification of the underlying root cause. Page 13 of 13

Error Handling Strategy

DECC/ SEC Subsidiary Document Consultation Draft V1.0 Error Handling Strategy Author: Date: 9 th May 2014 Page 1 of 8 Public DECC/ SEC Subsidiary Document Consultation Draft V1.0 Contents Error Handling