Business Process and Procedures Workstream

Transcription

1 National Smart Metering Program Business Process and Procedures Workstream SMI De-en business process Version Number: Version 0.2 Status: Draft Author: P Egger Date Published: 27 June 2010 File Name: bppwg workshop 14 outcome - rrp smi de-en stakeholder feedback register v02 (marked).docx Deleted: 1 Deleted: 18

2 A.0 General for Template AGL, v01 14/06/10: WHEN : Timing The term Timing is defined so all participants have a similar understanding. At the moment, it is not clear if this is the time that a participant can send a request, or when the request will be actioned. Also, is it dependent on individual business operation times? A.1 AGL, v01 14/06/10: WHEN: Frequency is NOT REQUIRED as Frequency requirements should be covered off in the service and performance level requirements for each function. If used, Frequency should be defined so all participants have a common understanding. A.2 AGL, v01 14/06/10: HOW MANY: requests Not required as no of request requirements should be covered off in the service and performance level WGL, v03 20/06/10: Good point. Timing and Service level have been reworked into Initiator Timing and Counterparty Timing respectively. A description has been provided (in the CPR template v05) for both, including examples. Please let me know if further clarification / explanation would be of benefit. Remove this section WGL, v03 20/06/10: Not actioned in RRP v03. It is requested that the stakeholder reflect further on this concern. For the CPR, frequency refers to an estimation of the number of occasions action is taken to send transactions in a nominated period, or if random, the source trigger for the action (for example, when requested by a customer). This information helps to improve understanding of the context of the business process. A definition has been provided (in the CPR template v05). If it is not possible to provide the relevant frequency information, then record not able to estimate at this time. Remove this as should be incorporated in the Performance levels WGL, v03 20/06/10: Not actioned in RRP v03. It is requested that the stakeholder reflect further on this concern. For the CPR, HOW MANY refers (marked).docx Page 2 of 27

3 requirements. This should be similar to existing b2b protocols contained within the technical B2B documents. to an estimation of the number of transactions in a nominated period, irrespective of whether the transaction initiating events are uniform or random. The number is the total for the entity as supplied to the NEM. A description has been provided (in the CPR template v05). This information helps to improve understanding of the context of the business process. If it is not possible to provide the information, then record not able to estimate at this time. A.3 General for RRP: AGL, v01 14/06/10: The scope of the De-en process is from when the Deen request is initiated to when the meter data (final read) is delivered. Any activities prior to sending the request are discretionary and the process should make a clear distinction between the Pre activities of a process and the process itself. These pre activities include: 1. Check status 2. Request supplementary information. AGL requires these to be discussed as a separate generic process that may be applied as a pre activity to all processes which would capture the new standing data requirements in MSATS. A.4 AGL, v01 14/06/10: All references to CSP need to corrected to read as CSFP (Customer Service Functions Provider) WGL, v03 20/06/10: It was agreed in workshop#13 to identify the core De-en process with a distinctly coloured path. This has been included as a first draft in v03 of the RRP. Once the core path has been agreed by the WG members, the remainder of the process steps form pre or post process steps. It is expected that the intent of this concern will be addressed during the next few workshops. WGL, v03 20/06/10: Agreed. Changes made to all entries. (marked).docx Page 3 of 27

4 A.5 AEMO, v04 21/06/10: Cover Page certain sections require modification or clarification as per the suggesting wording: 1. Introduction - This Cover Page has been prepared to represent the following Proposed NEM business processes that have been used for the development of User Requirements: 3. Objective - The objective of the Role Requirements analysis is to determine the requirements of each Role that will use the nominated business process when SMI capability is available to that process. 4. Scope - The Role Requirements analysis for all Proposed NEM business processes has been restricted to the mandate period. 6. Common Role Related Principles please clarify principle. A.6 AEMO, v04 21/06/10: Replace all references of needs to requirements as this is a requirements paper. Deleted: needs A.7 AEMO, v04 21/06/10: ATTACHMENT 3 - Control point records This information is useful however the records take up too much space in the document and contain solutions. Suggest using the what the when and the who and use that in the main section to identify the requirements. And remove the Where and how as Section 23 Common Needs changed to NEM Requirements to align this section with the title of the document so as to address in part the intent of this suggestion. (marked).docx Page 4 of 27

5 they are solution based and should not be documented in a requirements paper. Suggest using them in the solutions paper. 1.0 RRP No: AEMO, v04 21/06/10: NSMP BP Version: 3.0 Status: 4.0 Date: 5.0 Long Title: AEMO, v04 21/06/10: The term NEM Business Process needs to be defined. Service Order or Meter Data is a NEM business process, de-energisation, reenergisation etc are not. 6.0 Short Title: 7.0 References: AEMO, v04 21/06/10: Missing reference document which was provided by AEMO on the 02/06/2010 as a reference for the Business Processes analysis. 8.0 Objective: AGL, v04 21/06/10: The word De-en is an abbreviation and does not describe the process effectively. Please provide a rationale for the suggestion to describe the concern/issue and populate the suggested wording column with an appropriate statement. ERMB Process Diagrams v 6.1 Please advise which flowcharts are to be / have been used in forming the SMI De-en process, otherwise it may be more appropriate to record this document in the Cover Page. SMI De-Energisation process. This should be consistently used throughout the document. In addition, the term SMI de-energisation has been substituted for De-en in the Control Point Records to address the intent of this (marked).docx Page 5 of 27

6 suggestion. 8.1 AEMO, v04 21/06/10: AEMO suggests that the objective of the deenergisation process is reworded as per suggested wording. 9.0 Scope: AGL, v04 21/06/10: d) SMI De-en covers remote opening of the Supply Contactor only. 9.1 AEMO, v04 21/06/10: Uncertain of the scope of the scope. Are the items within the scope defined for the process or the solution? Scope item (d) appears to be the only scope item that is an accurate scope statement. Should the document contain what is out of scope? i.e. Re-energisation process. 9.a.1 AGL, v04 21/06/10: An SMI De-en service request can only be initiated by the FRMP Suggest adding the word current before FRMP to remove any ambiguity around connection/disconnection requests from multiple retailers. The objective of the SMI De-en service Process is to prevent unauthorised consumption of customers consuming electricity without authorisation by the FRMP when electrical safety isolation is not required. d) SMI De-en covers remote opening of the Supply Contactor only ADD: This process also covers local opening of the supply contactor for exception purposes. 9. (d) SMI De-en process covers remote operation opening of the supply Contactor only. An SMI De-energisation service request can only be initiated by the current FRMP This should be consistently used throughout the document. In addition, the short title SMI De-en has been changed to SMI De-en process The scope can include matters that are out-ofscope. (marked).docx Page 6 of 27

7 9.a.2 AGL, v04 21/06/10: An SMI De-en service request can only be initiated by the FRMP. The group should consider the situation where the current retailer sends a deenegisation request where a re-energisation has been requested within a specified timeframe, whether this is from the same or prospective retailer. 9.b & 9.c AGL, v04 21/06/10: b. The SMI De-en service request can only seek to stop supply at a premise for the purpose of (a) move out, (b) non-payment, and (c) satisfying a customer request c. The SMI De-en service request must not be used to request electrical safety isolation at a connection point. Suggest combining points b and c as the later clarifies the first point. b. The SMI De-energisation service request can only seek to stop supply at a premise for the purpose of (a) move out, (b) non-payment, and (c) satisfying a customer request. The SMI Deenergisation service request must not be used to request electrical safety isolation at a connection point SMI Functions: AEMO, v04 21/06/10: The identified business processes support the new SMI functionality, they are not assigned functions. Please update description to reflect the suggested wording Roles: AGL, v04 21/06/10: Add Local Retailer (LR) 11.1 AEMO, v04 21/06/10: 1. The Roles defined must be participants in the NEM who need to know the status of the Add Local Retailer (LR) 1. (a) Current FRMP; (b) Service Provider [CSFP]; (marked).docx Page 7 of 27

8 Supply Contactor, i.e. the customer and the (c) Service Provider [MDP]; Market System are not participants in the NEM. (d) DNSP Responsible person The supply contactor status does not impact the [DNSP - mandate]; status of the NMI or does it? Have we defined (e) Customer; that yet? The only Roles applicable are as per (f) Smart Meter; suggested wording. (g) Market Systems; (h) AEMO. 2. Update description to reflect the suggested wording. 2. The following NEM participant s entities are SMI visual context: 13.0 Limitations with existing NEM Procedures: AGL, v01 14/06/10: In the B2B service order process for De-en (NSW), there is an obligation around the requirement for the FRMP & DNSP to deliver unbranded envelope to customer s premises to advise the customer that he has been disconnected. If the process occurs via Remote means, this clause might need to be reworded that the written notice of disconnection might not be required AGL, v04 21/06/10: Limitations with existing NEM procedures Suggest adding requirement around retailer to The FRMP providing a letter to DNSP for NSW De-energisation for Non-Payment for the notice to be left on-site (Refer d.3 of AEMO B2B Service Order WGL, v03 20/06/10: Not actioned in RRP v03. This appears to be a new limitation with a NEM Procedure. No problem in including this in the analysis. It needs to be first recorded in the spreadsheet in the appropriate page, and then taken through to the appropriate GRAPL. To do this the WGL needs more information on the nature of the problem. Please nominate the clause in the procedure where this matter arises. Subsequently addressed by AGL in 13.1 below. Limitation to be recorded in spreadsheet and worked through to the GRAPL. Spreadsheet page <<to be provided>> (marked).docx Page 8 of 27

9 provide letter in NSW Electricity market to the DNSP Process). Gap Analysis page <<tbp>> for a disconnection for non-payment. GRAPL# <<tbp>> AEMO, v04 21/06/10: AEMO Suggests that the GRAPL limitations are not required in the requirements paper. If there is a preference by the other members to add the summary of the GRAPLS, the limitations should be translated into issues without referencing to solutions. Issues can then be used in the ICF/Whitepaper. As per the suggested wording: NSMP07 Supply Contactor Operation dot point 2 limitation # 2, 3, 7, 6, 8, 9, 10, 12. # 2, 7, 8, 9 Current De-en times require review to ensure they are applicable do not cater for SMI operation. # 6 Current Applicable events and their codes may require review to ensure they are applicable for SMI operation. limit reasons why SMI did or didn t operate # 3 Due to additional SMI functionality, Tthe FRMP may requesting supplementary additional information from the DNSP. # 10 The Current CATS_NMI_Data table will require review to ensure all SMI data are included may limit operation of Supply Contactor # 12 As a result of additional SMI functionality, there is a requirement to introduce new transactions between the The FRMP sending a request to and the DNSP. Deleted: (marked).docx Page 9 of 27

10 14.0 Role Functionality Tables: 15.0 Role Related Principles: AEMO, v04 21/06/10: AEMO suggests that the description of role functionality tables is changed to the suggested wording: Tables would need to change to reflect NEM participants, as per feedback for section 11 roles AGL, v01 14/06/10: The current FRMP requires visibility of the current Supply Contactor status. Meter Supply Contactor status and NMI status are to be readily visible 15.1 AGL, v01 14/06/10: The current FRMP requires visibility of the change in Supply Contactor status to be recorded in the event log also The extent to which an entity is interested to know that the Supply Contactor has been switched to the OFF changed to the open position (equivalent to the contactor being in the Open state) is shown in Table 1, as follows The current FRMP requires visibility of the current Supply Contactor status. Meter Supply Contactor status and NMI status are to be readily visible including the provision of method for disconnection (remote, fuse, tails, pole etc) Supply Contactor status change to be included in event log. The Functional Specification uses 2 terms in explicit ways. The terms are OFF position and open state. The suggested wording has mixed these terms so that they are no longer consistent with the Functional Specification. Please reconsider this suggestion. WGL, v03 20/06/10: Not actioned in RRP v03. This principle and matter was addressed in workshop#13. A change was made to this principle, however, the point raised in the Stakeholder feedback was not fully understood. It was initially considered that reference to fuse, tails and poles was out of scope for the SMI De-en business process. However, in the context of understanding the state of the connection point prior to submitting a SMI De-en request, it is appreciated that this information would be appropriate. Accordingly, this comment has been included in v04 of the RRP for further discussion by the BPPWG. WGL, v03 20/06/10: Not actioned in RRP v03. Table 3 in Line Item 14 clearly shows that this condition will be met in accordance with the (marked).docx Page 10 of 27

11 Functional Specification. Accordingly, this suggestion is already incorporated in the FS AGL, v01 14/06/10: The current FRMP requires visual display on meter to indicate status of de-energisation contactor when a De-en has been implemented 15.3 AGL, v01 14/06/10: The HAN needs to continue operating when the site is deenergised. Many Zigbee based devices (especially IHD) are battery driven, and should continue to function post deen. Visual display on meter to indicate status of de-energisation contactor when a De-en has been implemented Meter to continue to send info to bonded devices that have battery as power source WGL, v03 20/06/10: Not actioned in RRP v03. This is not a principle that relates to a business process or procedure. Rather, it appears to be a principle that relates to the Functional Specification. It is a working principle of the BPPWG that whilst the BRWG is active, such matters will be raised by the stakeholder in that forum. Accordingly, the WGL does not consider this suggestion to be relevant to the BPPWG at this time. Please discuss if a different position should be considered. WGL, v03 20/06/10: Not actioned in RRP v03. This is not a principle that relates to a business process or procedure. Rather, it is a principle that appears to relate to the Functional Specification. It is a working principle of the BPPWG that whilst the BRWG is active, such matters will be raised by the stakeholder in that forum. Accordingly, the WGL does not consider this suggestion to be relevant to the BPPWG at this time. Please discuss if a different position should be considered. (marked).docx Page 11 of 27

12 15.4 (common c.1) AGL, v04 21/06/10: A new status will be required for the Deenergisation 1. What happens to the CLC/R status when the supply contactor is opened/ De-energiseddo all the contactors open automatically we may need to understand this to ensure there is no flowing impact? via the supply contactor 2. What status is returned on completion of de-energisation request? The currently known statuses are: active (A)/Not energised(d)/extinct(x)/greenfield site(g) 15.5 (common c.2) AGL, v04 21/06/10: The method of disconnection must be readily visible for the meter 15.6 (common c.3) AEMO, v04 21/06/10: What is the definition of the term visible? i.e. (e) Other methods of disconnection are to be visible if they have been applied to the connection point (such as fuse, pole, tails, pit, etc) [AGL] 15.7 (Common f) AGL, v04 21/06/10: Where the De-en service can t be performed by the SMI, the CSFP will advise the current FRMP (Common g) AGL, v04 21/06/10: A FRMP can request SMI De-en to be applied to a meter level. Other methods of disconnection are to be visible if they have been applied to the connection point (such as fuse, pole, tails, pit, etc) Where the De-en service can t be performed by the SMI remotely, the CSFP will advise the current FRMP. A FRMP can request SMI De-en to be applied at either a NMI or meter level. In regard to the status of the CLC/R, the Functional Specification appears to be silent on this matter. I will seek clarification from MG on this point and advise further. At this level of the design, the status returned is Supply Contactor in the open state. The suggestion of a new status for the Supply Contactor is a matter for the Options Paper. Please clarify how this suggested wording modifies the current principle. Please provide a rationale for the suggestion to describe the concern/issue and populate the suggested wording column with an appropriate statement. For example, please provide your understanding of the meaning of the term visible and propose that s the definition to allow WG members to consider your contribution. (marked).docx Page 12 of 27

13 15.9 (Common i) AEMO, v04 21/06/10: Need to remove references to solutions in all principles, as per example in suggested wording for (i): (Common j.1) AGL, v04 21/06/10: Where a De-en service request does not contain a preferred time, only a preferred date, the CSFP will batch service requests and the batch process will be performed in accordance with the agreed service levels [TBD] AGL: Assuming a solution is not preferred while defining role requirements (Common j.2) AGL, v04 21/06/10: Where a De-en service request does not contain a preferred time, only a preferred date, the CSFP will batch service requests and the batch process will be performed in accordance with the agreed service levels (i) A De-energisation service request will not be used by a FRMP to de-energise a customer s site if the customer has requested the site to be isolated so as to allow electrical work to be performed at the premise. In this case, an Additions and Alterations request must be used. Remove (j) or remove the batching solution to ensure that the principle is agnostic of how this is done. Where a De-en service request does not contain a preferred time, only a preferred date, the CSFP will execute in accordance with the agreed service levels Please provide suggested wording for all principles that are of concern. The suggested wording in this feedback has been transferred to the General suggestions table in the RRP for SMI De-en for the nominated principle only. This implies a solution (batching) rather than a principle (Common k) AGL, v04 21/06/10: If the remote opening of the Supply Contactor is not possible the DNSP will (a) advise the FRMP of this situation, and (b) advise the FRMP that the Supply Contactor will be opened remotely or locally but not If the remote opening of the Supply Contactor is not possible the CSFP will (a) advise the current FRMP of this situation, and (b) advise the current FRMP that the Supply Contactor will be opened remotely but not before the original scheduled time (marked).docx Page 13 of 27

14 before the original scheduled time. or locally. In any instance, the Supply AGL: contactor should not be opened before the original requested scheduled time NEM business process flowchart: 1. Replace DNSP with CSFP The intent of the last words in the sentence is not clear and need to be re-worded. AGL, v04 21/06/10: Process for verifying standing data (CP#02). step BP01.9 Obtain and send Information. A step needs to be included for the CSFP to query the market systems to determine if the data that current FRMP requested verification on is out of alignment. If the information is different then the CSFP should obligated to update the market systems. means that the CSFP has a window of time in which to open the Supply Contactor without having to inform the FRMP. In that window, the CSFP may open the SC by SMI remote or SMI local depending on the circumstances confronted by the CSFP and the SLR agreed with the FRMP. Please suggest revised wording to assist in its clarification. Modify flowchart and add a new principle AEMO, v04 21/06/10: AEMO suggests that the Process Flowcharts is moved to the start of the document as the analysis of the flowchart highlights the requirements for this paper Current FRMP unique needs: (a) AGL, v01 14/06/10: Section 17: The current requirement is that the FRMP needs to know the SMI capability of the site A Service Level is required for updating Market Systems. The service levels should not only be on the WGL, v04 27/06/10: These points have been incorporated in v04 of the RRP and will be discussed at a subsequent workshop. (marked).docx Page 14 of 27

15 timeframe to update the system but include accurate information (a) AGL, v04 21/06/10: The FRMP needs to know the SMI capability of the site [a Service Level is required for updating Market Systems] AGL: the information is insufficient and needs to be more descriptive of the actual requirement (a) AEMO, v04 21/06/10: Remove reference to solution as per example in suggested wording: The FRMP needs to know the SMI capability of the site [a Service Level is required for updating Market Systems] SMI Capability of the site Enabled/ disabled status Method of disconnection (pole, fuse, tails, pit, remote SC, local SC) Service level for updating MSATS. The service level should not only be the timeframe to update the system but include accurate information. (a) The FRMP needs to know the SMI capability of the site [a Service Level is required for updating Market Systems] o The current requirement is that the FRMP needs to know the SMI capability of the site (AGL ) o A Service Level is required for providing changes to supply contactor status to the market updating Market Systems (AGL) o The service levels should not only be on the agreed timeframe to Suggested wording transferred to the Suggestions table in Section 17 of the RRP for SMI De-en. Suggested wording transferred to the Suggestions table in Section 17 of the RRP for SMI De-en. (marked).docx Page 15 of 27

16 update the system but include and accuratecontain information (AGL ) 17.1 AGL, v01 14/06/10: Section 17 The FRMP needs to send an electronic request for a De-en service to the CSP CP#01 Check status This should highlight the need by the business to have remote de-energisation as per the defined service level, allowing the billing of a customer to a particular point in time. AGL, v0.1 14/06/10: This is a discretionary pre activity that the FRMP may undertake if the standing data in systems requires validation with the Market system. What the process should cover is the additional standing data fields in MSATS required to support FRMP back office activities. These fields will also require a timing obligation in updating the information by the Service Provider. Some more points for consideration: Whether a new transaction is required or not, depends on whether the current transactions are sufficient. Procedures should allow flexibility to request specific information from MSATS relevant to that service. This should also be added to principles. For De-en service, NMI status and Disconnection method are required. Disconnection method may be one of the following: Suggest words electronic request allowing for a remote and manual de-en service to the CSP? (marked).docx Page 16 of 27 WGL, v03 20/06/10: Not actioned in RRP v03. It was agreed at workshop#13 that the business process would be for SMI De-en using the remote facility. It would be up to the CSFP to determine if local operation would be performed. Consequently, there is no need for the FRMP to request local operation. WGL, v03 20/06/10: Not actioned in RRP v03. A number of the points in the concern appear to be oriented towards solution options. The RRP is only focused on the needs of entities, including details of current needs (eg. Type 2 NMI discovery would be sufficient detail) plus additional needs. If the current transaction is sufficient, then there is no limitation associated with the introduction of the SMI. Deleted: CP#01, Deleted: Check status, The relevance of the disconnection method at the time of status check is self-evident now that this has been pointed out and accordingly has been added to RRP v04. Happy to transfer the first two comments

17 1. Fuse to the Options Paper step, please advise. 2. Pole 3. Supply Contactor 4. Pit 17.3 CP#01 AGL, v04 21/06/10: add: Inbound content: required information to be added: 1. CLC/R status Suggested wording transferred to CPR#01 of 1. CLC/R status 2. Number of phases 2. Number of phases 3. Annual consumption 3. Annual consumption 17.4 CP#01 AGL, v04 21/06/10: HOW Many: What is the basis of 10 transactions per day 17.3 CP#02 Supplementary information, AGL, v0.1 14/06/10: This is a discretionary request and FRMP may make use of the request during the preparation process if required. This transaction needs to be similar to a Verify Meter Data [VMD] transaction in that it provides the FRMP the capability to validate the standing data in MSATS from the Service Provider Initial estimate to act as a starting point. The FRMP is expected to rely on the quality of its internal systems for the connection point status. It is expected that the FRMP would only seek clarification of data from marker systems when there was doubt about the internal FRMP system data. The quantity 10 was determined from the scenario where doubt was expressed on 0.1% of the daily transactions and there were 1,000 CP#4 transactions a day. Please rework these numbers to provide a value that is more consistent with the company s view. Deleted: WGL, CP#02, v03 20/06/10: Deleted: Not Supplementary actioned in information, RRP v03. The point raised appears to be more like a solution option. The needs of the FRMP at this Control Point were discussed in workshp#13 and it was decided to reorient the transaction to verification of standing data. Please see RRP v03 for change in terminology. (marked).docx Page 17 of 27

18 This transaction will need to be assessed as a separate process to validate the requirements as it will apply to a number of services as a pre activity by the FRMP when required On the request of the FRMP to validate the information held in MSATS, if the information is inconsistent, the Service provider should be obligated to update information in MSATS as soon as possible in addition to providing the FRMP with the corrected information. MSATS should be updated in a timely fashion and data should co-relate CP#02 AGL, v04 21/06/10: Basis of defining FREQUENCY and HOW MANY are not clear Consistent definition of the Frequency and How many with the purpose of intent There is an unresolved issue in my mind. It seems more appropriate to send the transaction to the MP rather than the CSFP. This point requires further clarification. Any comments? Happy to transfer the first two comments to the Options Paper step, please advise. The definition of frequency is provided in the CPR templatev05, as follows: An estimation of the number of occasions action is taken to send transactions in a nominated period, or if random, the source trigger for the action. Examples: (a) One occasion per day. (b) Multiple occasions per day. (c) One occasions per month on average. (d) Triggered by customer (e) Not able to estimate at this time. The definition of How Many is provided in the CPR templatev05, as follows: An estimation of the number of transactions expected to be sent per day on a market basis. For example: (marked).docx Page 18 of 27

19 (a) Less than 1 transaction per day on average. (b) 1 transaction per day. (c) More than 10 transactions per day. (d) More than 50 transactions per day. (e) Not able to estimate at this time CP#02 Entities: AGL, v04 21/06/10: Please add Market Systems 17.3 CP#02 Address: AGL, v04 21/06/10: FRMP should not supply this information as it is a standing data query. The only information that is relevant is the NMI CP#04 Send De-en service request AGL, v0.1, 14/06/10: CP # 04 Send De-en service request Defining the priority of the request should be governed by business rules and the timing of the request CP#04 AGL, v0.1, 14/06/10: CP # 04 Send De-en service request (marked).docx Page 19 of 27 Please add Market Systems Not actioned in RRPv05. CP#02 does not interface with market systems. Please refer to the flowchart. Thanks for the clarification. Address removed from the Control Point Record. Deleted: WGL, CP#04 v04 27/06/10: Not actioned in RRP v03. This concern appears to relate to the Content row. Please be more specific. The Content row should include the information that the FRMP wants / needs to convey to the CSFP. Explicitly which pieces of data will be extracted from the business rules and the timing of the request that can be recorded in the Content. If it is not clear at this time, then a general expression will suffice for the moment. The sentence will be qualified with this concern in the next version to act as a prompt. Deleted: WGL, CP#04 v04 27/06/10: As there is no Service Level Agreement in

20 Every DEEN request initiated by the FRMP should also have a time to live or lifetime. The service may no longer be required after that time as expired. This should include the number of re-tries and be governed by the service level associated with that service CP#04 AGL, v0.1, 14/06/10: CP#4. Additional transaction: FRMP Check 17.7 CP#04: Outbound Content After receiving the FRMP request for DEEN, CSFP should validate if the FRMP is the current FRMP and is allowed to request de-en at that time. The request should be rejected if the FRMP check returns inconsistent results. AGL, v04 21/06/10: Please add; 1. Method of disconnection 2. Priority 3. Validity of the request (start date and time and end date and time) 4. Customer Contact Information Please add; 1. Method of disconnection 2. Priority 3. Validity of the request (start date and time and end date and time) 4. Customer Contact Information place at the moment, the lifetime point has been incorporated in the WHAT Outbound Content row of the CPR (v04 of the RRP). Deleted: WGL, CP#04 v04 27/06/10: The concern has been incorporated into the WHAT Inbound Content row for consideration at workshop#14. Suggested wording transferred to CPR#04 of 17.8 CP#05 Send Planned Schedule AGL, v0.1, 14/06/10: This step is relevant to the FRMP only if the De-en service request is prospective. There is no point in receiving the schedule for requests which will require immediate action (depending upon priority). Deleted: WGL, 7 v04 27/06/10: Deleted: No CP#05 problem in qualifying the CPR with this statement. The timing associated with the Deleted: CP # 05 Send Planned Schedule term prospective needs to be provided. For example, does it mean any request that is for tomorrow, next week, next month? Incorporated in the CPR (v04 or RRP) with prompt for more information. See (marked).docx Page 20 of 27

21 response in 17.9 below 17.9 CP#05 Objective 7.10 CP#06 Outbound Content AGL, v04 21/06/10: Prospective means in the future or forthcoming. Planned schedules are significant only if the FRMP is scheduling a De-energisation request in the future. If the request conisists of the time of action then it should be implied that the request will be actioned as per time requested. AGL, v04 21/06/10: The failure notification should advise the current FRMP with the options ie local SC or other time etc, add Advise FRMP with options in case the remote de-energisation has failed The wording of the Objective has been qualified in CPR#05 to accommodate the suggestion. Please advise if the qualification is not adequate. Suggested wording transferred to CPR#06 of CP#06, #10, #12, #13, #14 AGL, v0.1, 14/06/10: This should incorporate the BAU completion process framework. There should be a single (common) format for the DEEN service notification. This notification should cater to all outcomes for e.g success/fail. In case of FAIL, there can be additional information such as number of retries, reason for failure (reason code etc), site access issues, last attempt (local/remote), priority, workaround and planned schedule for manual de-en. Deleted: WGL, 8 v03 20/06/10: Deleted: Not CP#06, actioned #10, #12, in #13, RRP #14 v03. My understanding is that the fail case would not invoke CPR#10, #11, #12, #13, #14, as this is covered by CP#06. PE to discuss with SB to clarify whether CP#06 covers the intent of this concern CP#08 Outbound Content The difference will be the timeframe (service level) and the information contained in the completion as a reason for failure AGL, v04 21/06/10: Command completed message, if appropriate. Command failed message, if appropriate. Command completed message with date time stamp, if appropriate. Command failed message with date time Suggested wording transferred to CPR#08 of (marked).docx Page 21 of 27

22 QOS Event Log (SC opened). NMI and meter serial number. AGL: changes suggested stamp, number of remote retries and reasons for failure, if appropriate. QOS Event Log (SC opened). NMI and meter serial number CP#09 : Outbound Content CP#10 Outbound Content CP#11 : Outbound Content AGL, v04 21/06/10: Please add: reasons failure and site visits, mode of disconnection (pole, pit, fuse, tails), priority Suggested wording transferred to CPR#09 of AGL, v04 21/06/10: Please add: QOS events log report Suggested wording transferred to CPR#10 of AGL, v04 21/06/10: Please add: Validated and substituted interval data, QOS events log details. Please note that since there are new meter attributes and settings, MDFF might not be sufficient. A new mechanism may be required CPR#12 AGL, v0.2 14/06/10: BP01 De-en Service Send Notification SC Opened (p24) Content Please add: Validated and substituted interval data, QOS events log details Suggested wording transferred to CPR#11 of Add Deleted: WGL, 9 v03 20/06/10: - Applicable cost of Service Formatted: Not actioned Font: Not Bold in RRP v03. This concern - Disconnection Method (pole, appears to relate to Control Point Record Deleted: CPR#12 in full document fuse, remote etc) #12. It was agreed in workshop#13 that only SMI operation was in scope. Therefore, either remote or local SMI would be appropriate. If these methods were not available for some reason, the FRMP would be advised by the CSFP via a transaction at CP#06. The FRMP would then submit a separate request to initiate a pole or fuse disconnection. There should be no additional cost beyond the agreed (marked).docx Page 22 of 27

23 charge for SMI operation, therefore this information has not been considered appropriate to add to the CPR CP?? AGL, v04 21/06/10: The Event log details will be required for this request. It is suggested that event logs will be provided in the metering data. AGL suggests that this is a solution and the requirements should be agnostic of this option until an analysis has been undertaken CP?? Outbound Content 18.0 CSP unique needs: 19.0 MDP unique needs: 20.0 RP[DNSP] unique needs: 20.1 CP#01 Check connection point status information AGL, v04 21/06/10: Should include: Applicable charges for the Service. AEMO, v04 21/06/10: CSP Is not a NEM participant therefore should be removed. AEMO, v04 21/06/10: Does the MDP need to know the status of a supply contactor if it does not correlate to the status of the NMI?? AEMO, v04 21/06/10: This needs to be replaced with the DNSP as per section 11. SPAN, v04 21/06/10: As party responsible of maintaining market systems the DSNP/RP/CSP considers that only selected inbound content is relevant to the Please add: Applicable charges for the Service. Items incorporated off the power point presentation: Information to describe whether ARM functionality is Please advise which CP this feedback comment relates to.. Please advise which CP this feedback comment relates to.. It is reasonable for the MDP to know the status of the supply contactor as this information is part of the validation check / investigation that the MDP must undertake. This information will be provided at CP#10 by virtue of the QOS Event Log which has been added to RRPv05. Suggested wording transferred to CPR#01 of (marked).docx Page 23 of 27

24 process. being used NMI status Metering installation classification and Meter type (SM, AMI or other) Requestor needs information to determine whether there is an expectation that the supply contactor will be operated remotely or locally Items not incorporated off the power point presentation: Meter attributes: Meter configuration details not relevant to supply contactor process, it may be relevant to another process Meter attributes: Energy measurement channels that have been configured not relevant to supply contactor process, it may be relevant to another process Meter attributes: Customer Service function settings not relevant to supply contactor process, it may be relevant to another process (marked).docx Page 24 of 27

25 Meter contactor status not relevant to a Market System Fuse status not relevant to a Market System 20.2 CP#01 Check connection point status information 20.3 CP#02 Request supplementary information 20.4 CP#02 Request supplementary information 20.5 CP#03 Request supplementary information Process advice The intention of request supplementary information is not to verify the Address and Name & Address of customer Process advice As party responsible for responding considers that only selected content is relevant to the process. The Service level will be at least as robust as the Service Levels for CP#12. Remove Address and Name & address of customer The Service level will be at least as robust as the Service Levels for CP#12. Items incorporated off the power point presentation: Information to describe whether ARM functionality is being used NMI status Metering installation classification and Meter type (SM, AMI or other) Requestor needs information to determine whether there is an expectation that the supply contactor will be operated remotely or locally Please clarify, as I am not sure what this means. How do I incorporate the suggested wording into the CPR? Point noted. The address row in the CPR has been deleted. Please clarify, as I am not sure what this means. How do I incorporate the suggested wording into the CPR? Suggested wording transferred to CPR#03 of (marked).docx Page 25 of 27

26 Meter contactor status Energisation status Method of last disconnection 20.6 CP#04 Send Deen service request 20.7 CP#04 Send Deen service request 20.8 CP#05 Send planned schedule 20.9 CP#06 Notify SMI failure CP#08 Smart Meter operation Not before and not after time is not for the requester to specify, rather they are constraints imposed by the jurisdictional regulator and by the DNSP/CSP in accordance with a Energy Safety Management Scheme. The following items should be added to the content section Responding with an expected time of De-en is only appropriate if the minimum Service Levels are high enough for near real time responses otherwise a system generated response would be more appropriate Time range in which De-en service was attempted is not relevant. The SMI could have been attempted multiple times. Providing the QOS log is overly prescriptive of a solution, an event log change could trigger a command response Remove Not before and not after time from the content section The following items should be added to the content section: Whether or not the De-en is for non-payment, Move-out or transfer to another FRMP. Any safety information from customer relevant to local deen. Content is dependent on the minimum Service Levels Time range in which De-en service was attempted should be removed Remove QOS Event Log Suggested wording transferred to CPR#04 of Suggested wording transferred to CPR#04 of Suggested wording transferred to CPR#05 of Would you please be more specific? Which row does this concern relate to? Why is the time frame not relevant? Please describe in more detail.. Suggested wording transferred to CPR#08 of (marked).docx Page 26 of 27

27 20.11 CP#09 Manual CSP/DNSP/RP needs to inform the field service Add content De-en of the SC personnel if there is a hazard on site for a De-En Any safety information from customer Suggested wording transferred to CPR#09 of relevant to local de-en CP#10 Send notification to collect metering data 21.0 Customer unique needs: 22.0 AEMO unique needs: 23.0 Common needs: 24.0 Infrastructure Performance Level: 25.0 Participant Service Levels: 26.0 Customer Service Standards: 27.0 Progress reporting: 28.0 Endorsed: The De-en process should not link to the meter read process. When a type 1-4 meter is deenergised a read is provided separately on the next day AEMO, v04 21/06/10: The customer is not a NEM participant therefore should be removed AEMO, v04 21/06/10: AEMO does not need to know the status of a supply contactor, unless it correlates to the status of the NMI. Remove CP#10 Suggested wording transferred to CPR#10 of Thanks for the clarification. The RRP will be adjusted to remove AEMO from the Roles (Section 11) and Functionality Tables (Section 14). Instructions: 1. Secretariat to include date of response and version of RRP (or other document) in which the alteration has been made, if applicable. (marked).docx Page 27 of 27

28 Version History: Version Date Description of change Amended by v June 2010 Initial version of template P Egger V Jun 2010 Updated with contributions from AGL, SPAN, AEMO. Published for discussion at workshop#14 P Egger (marked).docx Page 28 of 28