SMART METER TEXAS

1. SMART METERTEXAS PSWG Release Scope Items February 8, 2011

2. Browser Compatibility Assurance Modify Usage Report default date to 1 day in past CR013 Update FAQs CR020 Rollover explanation for Estimates/Actuals CR021 Add Hoc Reporting for 2-39 days from the UI On Demand Read & Poll Power Status CR015 Utility Enrollment Group Event Subscription and Notification CR 018 SMT Mobile Experience Federated SMT Access Release Scope Agenda

3. BROWSER COMPATIBILITY ASSURANCE

4. SMT recommends validating compatibility with the following desktop browsers: Internet Explorer 8 Chrome 8 Chrome 7 (maybe) Safari 5 Safari 4 Opera 10 (maybe) SMT will establish a regression team that will execute all transactions on the SMT portal for each browser version being validated This regression test will run in parallel with the Release 3.0 build cycle Incompatibilities will be fed into the standard defect resolution process and completed by the end of the SIT period UAT will execute regression testing against the browsers Browser Compatibility Assurance Overview

5. Browser Compatibility Assurance Browser Market Share Source =http://www.netmarketshare.com/browser-market-share.aspx?qprid=1

6. Browser Compatibility Assurance Browser Market Share by Version Source:http://www.netmarketshare.com/browser-market-share.aspx?qprid=2

7. MODIFY USAGE REPORT DEFAULT DATE (to 1 Day in the Past)

8. The Usage / My Smart Meters page currently defaults to 2 days in the past (e.g. on 2/6 the user’s usage page will default to 2/4) This enhancement will set the usage page to default to 1 day in the past as data processing enhancement lands interval data to the SMT data warehouse within 1 day. Modify Usage Report Default Date Overview

9. CO 13 UPDATE FAQS

10. An AMIT subcommittee is reviewing the current FAQs to consider any needed updates and the addition of new questions and answers This CO enables the implementation of these changes CO 13 Update FAQs Overview

11. CO 20 ROLLOVER FOR EXPLANATION OF ESTIMATES & ACTUALS

12. SMT 15 minute interval reports contain an Act./Est. column that contains an “A” for Actuals and an “E” for estimates This CO enhances this report to provide an explanation of Actuals and Estimates when the user rolls their mouse arrow over the column Act./Est. column CO 20 Rollover for Explanation of Estimates & Actuals Overview

13. CO 21 ADHOC REPORTING FOR 2-39 DAYS (from the UI)

14. The current design for usage report only allows the data for the date shown on screen to be exported. This CO will enhance the Export button to rout the user to the report scheduler to run reports This will protect the performance of the portal while making the exporting of data a more intuitive process for the user CO 20 Rollover for Explanation of Estimates & Actuals Overview

15. ON-DEMAND METER READ & POLL POWER STATUS

16. Functional Overview Provided to the ROR and TDSPs Meter Read returns the current meter read Power status returns on/off (line side) One ESIID/MeterID per request (BR-006.006) Invoked via API RORs are limited to: 1 successful power status request per day per ESIID , and 1 successful meter read per day per ESIID Not in scope Support for Customers, 3rd parties, Supplemental, Regulatory On Demand Meter Read & Power Status

17. CR015 Utility Enrollment Group

18. The Utility Enrollment Group (UEG) provides a mechanism to direct Load Control/Demand Response events to a specific group of devices The UEG permits the segmenting of devices under a single ESI such as distinguishing between upstairs PCT and downstairs PCT. When a Load Control Event is initiated, only LC/DR capable devices that belong to a specific UEG will act upon event message. The HAN Service Provider can create up to 255 groups of HAN Devices (Load Control Devices with SEP 1.0 Implementations) To target specific devices the HAN Service Provider needs to be able to set up and/or update the UEG in each HAN Device before sending a Load Control Event. Currently HAN Service Providers are able to target specific devices in the premises if they establish agreements with HAN Device Vendors who would set up the UEG value in the Device. If no agreements are in place, once a Load Control Event for a group of ESI IDs is requested and processed successfully, all LC/DR capable devices that are provisioned to a T-ESI accept and act upon event message. Background (1/2) 18

19. Background (2/2) Currently HAN Service Providers are unable to update the Utility Enrollment Group in a HAN Device Firmware programmatically and remotely. The business requirement to address this gap is to provide the ability to update the Utility Enrollment Group (UEG) for Load Control Devices with SEP 1.0 implementations through new SMT API interfaces. 19

20. Utility Enrollment Group (UEG) Scenario • TDSP Web Services and Meter Head End accepting LC/DR Event Message Collector/Relay/Router A UEG 14 UEG 14 ESIID 1 - REP A • Collector/Relay/Router broadcasts LC/DR message to T-ESI’s (i.e. meters) 4. Only LC/DR devices with UEG=14 under REP A accept and act upon event message 1a. SEP 1.0 complaint LC /DR message developed and executed Smart Meter Texas UEG 14 ESIID 2 - REP A UEG 120 Collector/Relay/Router B Service Provider initiates a device targeted Load Control Event (e.g., UEG=14) through the LC /DR Messaging API UEG 14 ESIID 3 - REP B UEG 120 4. Only LC/DR devices with UEG=14 under REP A accept and act upon event message • Collector/Relay/Router broadcasts LC/DR message to T-ESI’s (meters) UEG 37 HAN Service Provider = REP A ESIID 4 - REP A 20 UEG 14 20

21. Business Justification Given the multitude of HAN Service Providers and HAN Device vendors in the ERCOT marketplace, the option to dynamically update the UEG Value in capable devices provides more flexibility to the HAN Service Provider. HAN Service Provider is able to target specific LC/DR capable devices in the premises more easily. HAN Service Provider is able to dynamically group LC/DR devices belonging to a LC/DR program more easily. Example: In the 1st quarter of 2011 the Center for the Commercialization of Electric Technologies (CCET) will be implementing an Energy Efficiency Project and could use the UEG to target “x” home owners by sending “y” LC directly on the air conditioner and “z” LC through a thermostat. Customers can have more than 1 LC/DR capable device (e.g., PCT) in the premises and are able to decide which one could participate in a Service Provider program. Customers can select more than one LC/DR program from multiple Service Providers based on the number of LC/DR capable devices in the premises (note: overlap possibilities). 21

22. SMT will develop new API Interfaces to allow the HAN Service Providers to update the UEG of the HAN Devices. One API Interface between the REP and SMT to accept the request. One API Interface between SMT and the TDSPs to process the request. Both Interfaces will have request acknowledgment response back. Sample Required Data Elements in the UEG Message: Utility Enrollment Group: valid values are 0 through 255. ESI IDs paired with MAC Addresses. SMT will: Verify that no more than 50,000 MAC Addresses are sent in the request. Verify the HAN Service Provider’s access to ESI ID(s). Verify that the UEG has a valid value. Verify that the Devices are provisioned to the ESI ID and only send provisioned devices in the request to the TDSPs (desired) Create and send separate lists of ESI IDs with MAC Addresses for different TDSPs If a specific TDSP does not support the functionality, SMT will not send the request. Once that TDSP is ready SMT will start sending the UEG requests. Incorporate the UEG message type in the Message Log (subject to TDSPs ability to provide status messages). Functional Design (1/2) 22

23. Assumptions Only HAN Service Providers are able to send UEG messages. Note that only provisioned devices are LC/DR capable are able to accept UEG messages. HAN Service Providers are responsible to manage the UEG of the HAN Devices, the meter does not keep a record and SMT will not save the groups in the database. No Cancel UEG messages will be implemented. If the Service Provider wants to change the enrollment of specific devices, a new UEG message can be sent to override the previous denomination. HAN Service Providers are responsible for reacting to: HAN Service Provider Switch, Move-In, and Move-Out in regards to UEG denominations. For example: If the Customer chooses a new HAN Service Provider, the new provider must first re-enroll the devices in the premise to the appropriate group before sending LC events Functional Design (2/2) 23

24. EVENT SUBSCRIPTION AND NOTIFICATION

25. Overview SMT will become a broad events notification channel to the consumer managed by the SMT Events Subscription and Notification engine The events engine will be configured to present the option to send an event notification message to text, Twitter or email for defined audiences and message types Customers, RORs, 3rd Parties and Supplementals are able to subscribe to and receive portal event notifications SMT Event Subscription and Notification

26. Overview (cont’d) Residential customer subscriptions are at an account level and a subscription is for all ESIIDs associated with the account Non-residential, REP and 3rd Party subscriptions are at an entity level. Entity subscription is managed by Administrators Subscriptions are managed via the SMT user interface SMT Host creates Portal maintenance notifications and forwards them if users/entities have subscribed to receive them SMT receives TDSP meter event notifications and forwards them if users / entities have subscribed to receive them Portal events are destroyed after notifications are sent Meter events are destroyed after notifications are sent SMT Event Subscription and Notification

27. Event Subscription and Notification Event Subscription and Notification Framework and Portal Events

28. Event Subscription and Notification Requirements and Task 94

29. Event Subscription and Notification Requirements and Task 77

30. SMT MOBILE EXPERIENCE

31. Recent research shows that mobile data users are rapidly migrating from Non-Smartphones to Smartphones to get full browser experiences on their mobile devices To drive adoption SMT will add the ability to serve a mobile portal experience for its users This is accomplished with WebSphere Everyplace Mobile Portal (WEMP) SMT will develop a 2nd UI which is suited for mobile browsers As a user seeks to access smartmetertexas.com, the portal will read the browser type (e.g. desktop or mobile) of the user and serve the relevant UI to the user’s browser SMT Mobile Experience Overview

32. SMT Mobile Experience Browsers vs. Apps & Smartphones vs. Non-Smartphones App and Browser Usage by Mobile Device In August, 75.6 million mobile subscribers ages 13 and older used downloaded applications, with Smartphone users representing 60.4 percent, up from 43.6 percent in August 2009. For the same period, 80.8 million mobile subscribers used their browser, with Smartphone subscribers comprising 55.5 percent, up from 41.4 percent a year ago. Analysis – these trends suggest that Non-Smartphone mobile data users are converting to Smartphones to take advantage of superior data consumption abilities, leaving Non-Smartphones for non-mobile data users. Note: The graph on the right was made using the data from the table on the left. The trend lines are linear and were formed using Excel’s trend line feature. Source: http://www.comscore.com/Press_Events/Press_Releases/2010/10/Smartphone_Subscribers_Now_Comprise_Majority_of_Mobile_Browser_and_Application_Users_in_U.S

33. SMT FEDERATION

34. Allows consumers, residential and non-residential, to access SMT directly from their REP website, without registering on the SMT portal Once the consumer has become a customer of a REP, he follows standard REP process to gain access to his REP portal (not an SMT process) Once logged into the REP website, the consumer will click a link on the REP portal to access the SMT portal The link will serve two purposes: Establish the Federated Experience On first use pass the consumer’s REP Userid, password, ROR#, ESIID & Meter # If the meter is available, the consumer’s REP user identity will be established on SMT and access granted to the SMT portal If the meter is not available, the consumer will be presented with an online message stating such with an action for the user to call the REP. The REP would a initiate a Remove for Dispute transaction on SMT with the TDSP. Once the user is federated clicking the link will log the user in via Single Sign On (SSO) Federated consumers will land on the SMT authenticated home page(Federation user experience to be determined during design) SMT Federation Functional Overview

35. Thank You For The Opportunity To Discuss SMART METER TEXAS