Business Process and Procedures Workstream. Event Log Collection, Processing & Delivery process (BP05)

Business Process and Procedures Workstream Options Paper Collection, Processing & Delivery process (BP05) Version Number: Status: Author: Version 0.1 Draft P Egger Date Published: 07 February 2011 File Name: 05 bppwg bp05 options paper v0.1 (initial).docx

[Table of Contents] Version History: Version Date Description of change Amended by v01 07 Feb 2011 Initial version arising from workshop#23 outcomes P Egger Page 2 of 17

Typical Options Paper Preparation Process: Step# Process steps Progress Date 01 WGL provides skeleton Options Paper with reference to the GRAPLs and Completed 31/01/11 the Role Requirement Papers. 02 A workshop would be held to reaffirm the Objective and the Scope, to discuss the Procedures Framework, to identify various options and to Completed Workshop: #23 describe those Options, and to reaffirm the principles 03 WGL to update the Options Paper and publish a first draft of the Options Paper which would include the nominated options. Completed 07/02/11 04 Working Group members (out-of-session) will: Review the options; Provide feedback on the Options that has been owned and supported by that WG member; and Provide general feedback on the Options Paper. 05 WGL to update the Feedback Register based on the comments, and: Update the Options Papers based on the Secretariat response; Publish the revised Feedback Register and Options Paper for further consideration by WG members. 06 WGL to discuss business rules and indicative procedure clauses for each option with Option owner (out-of-session) to develop a comprehensive set of rules and indicative clauses for each Option. 07 WGL to update the Option Papers based on the comprehensive business rules and indicative procedure and republish. 08 A period of time is allowed for WG members to complete a detailed internal review of the Options Paper and provide Stakeholder feedback to WGL 09 WGL to revise the Feedback Register and the Options Paper with the stakeholder feedback comments and republish as a final draft 10 A workshop is to be held to finalise endorsement of draft final RRP PE: Blue Workshop: Dark red WG member review: Green WIP means Work In Progress WIP Due COB Fri 04/03 Page 3 of 17

Table of Contents: [Version History] 01. Options Paper : 02. Title: 03. References: 04. Objective: 05. Scope: 06. NSMP Requirements: 07. Option#01 Summary: 08. Progress reporting: 09. Endorsement: Attachment A Option#01 Attachment B Test of Options The hyperlinks can be used to navigate to and from a chosen Line Item in the paper. (1) Options Paper : NSMP Options BP05 [back] (2) Title [back] C, P & D process (3) References: [back] The following documents contribute directly to preparing the C, P & D process options: (a) GRAPL NSMP02 Remote Acquisition. (b) (c) (d) (e) (f) GRAPL NSMP10 Quality of Supply and Other Event Recording. GRAPL NSMP13 Meter Settings Reconfiguration BPPWG role requirements cover page. Role Requirements Paper C, P & D process (BP05). BPPWG Options Paper cover page. (4) Objective: [back] The objective of the SMI C, P & D process is to collect, process and deliver event logs from the SMI meter to parties entitled to this information in accordance with agreed service levels. Event Logs can be provided as a routine command or as the result of a special read request. (5) Scope: [back] (a) In-scope: (1) The availability of event logs to authorised parties that have been collected as a routine read; (2) The availability of event logs to authorised parties that have been collected as a special read; (3) The translation of the event log raw data to business codes; (4) Storage of the event logs; (5) The formatting of the event logs; and (6) The delivery of the event logs to authorised parties. (7) The immediate or early delivery of event logs associated with alarms to authorised parties. (b) Out-of-scope: (1) The collection, processing and delivery of metering data that may be done in conjunction with meter event logs, that is, the meter event logs and meter data are collected and delivered independently. Page 4 of 17

(6) NSMP Requirements: [back] The NSMP requirements that will allow participants to receive s and associated alarms and request adhoc readings of s at a nominated SMI meter are specified as follows: (a) (b) (c) (d) (e) (f) (g) (h) (i) (j) (k) (l) An SMI facility is required to provide the following features: (1) A meter with an electronic event log; (2) The event log to have: (i) (ii) recording and storage capability; storage capability of at least 100 records on a rolling window basis; (iii) capability to configure (enable or disable) each stored record for alarming on receipt of that record; (iv) The ability to send an alarm, once initiated, to the SMMS by remote electronic communications; (3) An SMMS that initiates a routine event log reading with a configurable reading period, or alternatively a SMI meter that initiates a routine event log reading with a configurable reading period and remote sending to the SMMS. (4) An SMMS to receive an ahdoc event log read request from a market participant and translate that request into a command without manual intervention; (5) A meter (on receipt of an alarm setting) that sends an acknowledgement to the SMMS; An SMI facility that sends daily readings of s on a routine schedule from the SMI meter to the, as configured by the ; [GRAPL#10/07] An electronic facility is required to transfer s and alarms from the to all authorised participants in short time frames consistent with Participant Service Levels. [GRAPL#10/07] An electronic facility is required to transfer information between participants in relation to adhoc reading requests and alarm setting requests in timeframes consistent with Participant Service Levels. [GRAPL#10/07, #10/08] The requires internal processing to validate incoming requests from participants to confirm the authenticity of the request. The requires internal processing to accommodate successful and unsuccessful acknowledgements received from the SMI meter. The requires internal processing to translate the raw language of the s and alarms into suitable business language (business codes); The requires internal processing to validate s and alarms received from the SMI meter. Rules are required to govern times of access to the electronic facility to allow participants to develop internal processes to support the receipt of s and alarms and the requesting of adhoc readings of s and alarm setting requests. Rules are required to govern the operation of the electronic facility, including the information that may be or should be transmitted between participants and the validation of that information. Rules are required to govern the turn-around time within a participant s internal business process. Rules are required for the to manage the requests for: (1) The prioritisation of adhoc reading requests; (2) The cancellation of the requests; and Page 5 of 17

(3) Delays in transmission due to request congestion. (m) Rules are required around the configuration of s. [GRAPL#10/01, #10/02, #10/03] (7) Option#01 Summary: [back] This Option covers the situation where xxxxxx Option#01 is analysed in Attachment A. The merits of Option#01 are as follows: (a) <<add description of merits>> (8) Progress reporting: [back] Progress has been reported to the IEC/RMEC as follows: (a) January 2011 monthly report. (9) Endorsement: [back] Record the entity that endorsed this paper (including date and version). Template comment - to be reworked Page 6 of 17

ATTACHMENT A Option 1 [Back to Table of Contents] [Back to Item 07] [Forward to Attachment B] The hyperlinks may be used to navigate around this Option. The contents for this Option are: A01 Description of the Option A02 Context diagram A03 Schematic diagram A04 Flowchart A05 Principles for the Option A06 Business Rules for the Option A07 Relevant procedure clauses for the Option A01 Description of the Option: [Back to top] Option 1 is owned by the following companies: Origin Energy, Ergon, Integral Energy. This Option adopts the following process entities: (i) (ii) (iii) (iv) (v) (vi) (vii) ; ; ; ; ; SMI meter;. (1) Process front end: Option 1 permits the current FRMP or to configure the alarm setting in the. The sends all alarm settings to the using the NEM B2B application. If a FRMP wishes to establish a new setting (one that the has chosen not to enable) then it must send that request to the for assessment. The performs a business validation to confirm that the request is from an authorised party, sends a setting to the SMI meter and examines the acknowledgement. Independently, Option 1 allows the FRMP,, and to request an adhoc read of the. Any of these parties can make this request to the. The performs a business validation to confirm that the request is from an authorised party, sends a command to the SMI meter and examines the returned by the meter. (2) Process back end: Option 1 requires the to advise the of a successful completion of the alarm setting request (or otherwise initiate a Fault Restoration process after an agreed number of retries), and populate with the appropriate or Standing Data. is required to have 7 x 24 updating and capability. Immediately the update is completed sends an update to the current FRMP and the. Independently, Option 1 allows the to undertake a translation process on the routine and adhoc event logs. The validates that translation and passes the translated data to for market storage. in turn sends the s to the authorised market participants. In addition, the receives alarms from the SMI meter and after assessment, passes this information to. in turn sends the alarm(s) to the authorised market participants. (3) Major departure from RRP:. (4) Compliant with Role Related Requirements: Yes. A02 Context Diagram: [Back to top] The context diagram is shown in Diagram A01. Page 7 of 17

DISTRIBUTION MANAGEMENT SYSTEM () Utility HAN HAN Environment HAN Environment Premise side Customer HAN secure tunnel SMI meter Internet Internet Gateway Event Log Internet Network side SMART METER COMMUNICATIONS NETWORK Transactions Transactions SMART METER MANAGEMENT SYSTEM () RETAILER MANAGEMENT SYSTEM () s (routine & adhoc) Alarm Standing data METER MANAGEMENT SYSTEM [] METER DATA MANAGEMENT SYSTEM () HAN Home Area Network MDM Meter Data Management System Metering, Settlements and Transfer Solution Master HAN Device Slave HAN Device B2B e-hub NEMNET Diagram A01 Option 01 Context Diagram The features of the Context Diagram for this Option are as follows: (a) (b) (c) (d) (e) (f) (g) The sends the alarm settings change request from the Distribution Management System to the via B2B after determining which settings are required. The notifies the FRMP of those setting via B2B. The FRMP has an opportunity to request additional alarm settings, in which case it sends the request to the from the Retailer Management System via B2B. The s internal system receives the request from the via B2B where the technical and business validation is performed and if successful, prioritisation is assigned to the request before it is passed to the SMMS queue. If not successful, the is notified. The SMMS processes the alarm setting request in accordance with the queue priority and the first-in-first-out rule. During processing, the SMMS converts the request to a setting instruction and transits that instruction to the SMI meter, which returns an acknowledgement message within the agreed Infrastructure Performance Level. The SMMS passes the acknowledgement message to the CFPS internal system for automated examination. If the message indicates that the setting was received successfully by the SMI meter, the : (1) notifies the via B2B of the successful completion of the request; and Page 8 of 17

(h) (i) (j) (k) (l) (2) updates with relevant alarm Standing Data. If the acknowledgement message from the meter indicates that the command was not received successfully by the SMI meter, the s internal systems undertake an agreed number of retries. If still not successful, the notifies the via B2B which initiates the Fault Restoration process. When an alarm is initiated by the SMI meter, the receives and validates that alarm, and then passes the alarm information to each of the market participants. When a routine reading is initiated by the SMI meter of the SMMS (depending on the purchasing decision) the receives, translates and validates the. If validation was successful, the passes the s to the Market Systems for storage. In turn, the Market Systems passes copies of the to the market participants. When an adhoc reading is requested by a market participant, the s internal system receives the request via B2B where the technical and business validation is performed and if successful, prioritisation is assigned to the request before it is passed to the SMMS queue. If not successful, the relevant market participant is notified. The SMI meter returns the adhoc reading, which is received, translated and verified by the CSFP. If validation was successful, the notifies the relevant market participant of the successful completion of the request, and passes the adhoc s to the Market Systems for storage. In turn, the Market Systems passes copies of the adhoc to the market participants. A03 Schematic Diagram: [Back to top] The schematic diagram for this Option is shown in Diagram A02. Alarm setting request: Request new setting Request new or change of setting Validate and SMMS queue SMI meter Acknowledge receipt of setting Action successful: tification of request completion s (routine, adhoc) s (routine, adhoc) Alarm Standing Data Change to Standing Data Action unsuccessful (routine, adhoc, alarms-set): Activate Fault Restoration process Rectify fault tification of request completion A04 Flowchart: [Back to top] Diagram A02 Option 01 Schematic Diagram The flowcharts for this Option are shown in Diagrams A04(1), A04(2), A04(3), A(04) and A04(5). Diagram A04(1) covers the actions undertaken by the FRMP and the to initiate an alarm settings configuration request on the in the meter. Page 9 of 17

AEMO Core process shown in blue Jurisdictional requirements shown in green Background information shown in purple Temporary located process shown in dark red OPTION#1 SMI Collection, Processing and Delivery flowchart market participants (adhoc) Undefined MARKET SYSTEMS Third Party CUSTOMER start BP05.01 Determine need for adhoc Event Log SMI De-energisation process CURRENT FRMP BP05.02 Request adhoc reading CP#01 Responsible Person and start BP05.03 Determine need for adhoc Event Log BP05.04 Request adhoc reading CP#02 start BP05.05 Request adhoc reading start BP05.06 Request adhoc reading CP#03 CP#04 (A) (B) (C) (D) (adhoc) page (adhoc) page (adhoc) page (adhoc) page SMI METER BPPWG RRP SMI C, P & D flowchart v03 Page 2/6 Diagram A04(2) Option 01 Flowchart market participant (adhoc) There are no breakout processes referenced in this flowchart. Diagram A04(3) covers the actions of the during the routine reading process. It includes the translation and validation of the readings, and storage of those reading in Market Systems, and the delivery of the s from the Market Systems to market participants. Page 11 of 17

AEMO Core process shown in blue Jurisdictional requirements shown in green Background information shown in purple Temporary located process shown in dark red OPTION#1 SMI Collection, Processing and Delivery flowchart (adhoc) Undefined MARKET SYSTEMS Third Party Adhoc CP#12 CP#13 CP#14 CP#15 BP05.20 Event Logs CUSTOMER CURRENT FRMP BP05.04 failure BP05.15 succseeful BP05.21 Event Log(s) Adhoc Adhoc Responsible Person and BP05.05 failure BP05.16 succseeful BP05.22 (s) Adhoc FRMP Market Market Market Market participants participants participants participants (adhoc) page (adhoc) page (adhoc) page (adhoc) page (A) (B) (C) (D) BP05.06 BP05.07 BP05.17 BP05.18 BP05.23 BP05.24 failure failure succseeful succseeful (s) (s) CP#01 CP#02 CP#03 CP#04 CP#07 CP#08 CP#09 CP#10 CP#11 Fault Restoration process BP05.03 tify validation failed BP05.19 Retry BP05.b Yes BP05.11 BP05.12 BP05.c Yes BP05.14 BP05.13 Send Were s Translate Validate Was validation tify successful Create file Event received? data data successful? completion Logs BP05.01 request BP05.02 Validate request BP05.a Was validation successful? Yes BP05.08 Adhoc request sent to meter BP05.10 s collected te: Basic business validation is applied to assess correctness of requesting party CP#05 CP#06 SMI METER command BP05.09 Events logged BPPWG RRP SMI C, P & D flowchart v03 Page 4/6 Diagram A04(5) Option 01 Flowchart (alarm - set) One breakout flowchart is referenced to the Fault Restoration business process (BP20). Diagram A04(6) covers the actions of the from the time of receiving an alarm from the SMI meter up until the time of directly notifying market participants of that alarm. Page 14 of 17

AEMO Core process shown in blue Jurisdictional requirements shown in green Background information shown in purple Temporary located process shown in dark red OPTION#1 SMI Collection, Processing and Delivery flowchart (alarms - set) Undefined MARKET SYSTEMS BP05.11 Standing Data Third Party CP#06 CP#07 CUSTOMER tify CURRENT FRMP BP05.12 end tify Responsible Person and BP05.04 failure BP05.09 completion notice Alarm settings BP05.13 end tify tify CP#01 CP#04 CP#05 FRMP & (alarms set) page (A) BP05.03 tify validation failed Fault Restoration process BP05.01 request BP05.02 Validate request BP05.a Was validation successful? Yes BP05.05 Alarm settings send to meter Retry BP05.c Were alarm Yes settings received by meter? BP05.07 Examine acknowledgement message BP05.08 Send Completion notice BP05.10 Send Standing Data SMI METER BPPWG RRP SMI C, P & D flowchart v03 CP#02 CP#03 Alarm settings BP05.06 Alarm settings stored Page 5/6 Diagram A04(6) Option 01 Flowchart C FSP (alarm - notify) There are no breakout processes referenced in this flowchart. A05 Principles for the Option: [Back to top] Based on the following assumptions, the option meets all the principles identified in the Role Requirements Paper for this business process. The principles are repeated below. A05.1 Assumptions: The following assumptions have been made in the analysis of this business process: (a) (b) (c) (d) The event logs will be stored separately in the meter. Each type of meter event can be sent immediately to the SMMS if the meter is so programmed. From (a) and (b) above it is assumed that the event logs can be collected, processed and delivered as separate files and not as part of the meter data file. The meter event logs and meter data are collected and delivered independently. The role related principles for the FRMP,,, and are as follows: A05.2 Generic Principles [from RRP Cover Page]: (a) (b) (c) (d) (e) Participant and market systems will contain the same information within the service level timeframes. Service levels must be measurable. Performance and service level requirements of this function must be carefully chosen to match the objectives of the smart meter program. Need to establish consistency in terminology between procedures and B2B procedures. There should be a new NEM Procedure for the Customer Service functions. Page 15 of 17

(f) (g) (h) (i) (j) (k) A single service request must be able to record multiple actions (and their sequence) for execution at a single connection point. A single service request must be able to record group commands (and their sequence) for execution at multiple connection points, except for a de-energisation request. If two or more roles are required to be involved in the completion of a request, only a single will be sent by the initiating role. The process will allow for an appropriate period of validation by all receiving roles. Where the validation fails, s will be sent to all impacted roles. There may be a cap on the number of command requests per day and an exception process for additional requests. All requests (commands and messages) will be queued and dispatched in the order they are received by the SMMS according to their priority, regardless of the size of the group. The Market Systems must remain the single source of truth regarding Standing Data. If the Market systems are incorrect, it is a requirement of the role that owns the standing data element to provide the necessary update. A05.3 Common principles: (a) (b) (c) (d) (e) (f) (g) (h) (i) Market participants include (as a minimum) the current FRMP,,,. A mechanism will extract all event log data from the SMI meter once per day and send that data to the relevant market participants. The role of the will provide the mechanism for extracting the event logs daily and for indentifying those events that will be reported immediately. The will perform a translation process prior to sending the event log information to market participants. The will perform a metering data extraction process and send that metering data (in its raw state) to the. The accreditation of the must include remote metering data collection, similar to the current MP(C) arrangement. Event logs are to be placed in the undefined Market Systems for access by market participants. Market participants can setup a standing request from the undefined Market Systems in order to have the event logs automatically delivered, without the need to manually access the event logs from that repository. The type of event information that is to be provided to each market participant is to be determined in the solution step. A06 Business Rules for the Option: [Back to top] The following business rules apply to this option: (1) Business rules arising from Principle xx: (2) (3) (4) Business rules arising from Control Point #xx: (5) (6) (7) Business rules arising from Process step BP01.xx: (8) (9) A07 Relevant procedure clauses for the Option: [Back to top] <<identify indicative clauses for this business process based on the business rules. Page 16 of 17

ATTACHMENT B Test of Options [Back to Main Contents] [Back to Attachment A] The hyperlinks may be used to navigate to and from the nominated process entities. The following tests are applied to each of the Options to determine the merit of the option: Are all the Common Role Related Principles satisfied? Are all NSMP Requirements satisfied are the explanations reasonable? Are all Unique Needs satisfied if not, why not? Are all limitations addressed by this option if not, why not? Are all Participant Service Levels addressed if not, why not? Are all Customer Service Levels addressed if not, why not? Will Roles be impacted favourably or unfavourably? Will NEM systems be impacted favourably or unfavourably? Will NEM Procedures be impacted favourably or unfavourably? OPTION 1: Page 17 of 17