Final - UCAIug



UtilityAMI-ENT Task Force

UTILITYAMI AMI-ENT USER REQUIREMENTS AND USE CASE DOCUMENT

UTILITYAMI-ENT AUTOMATED DATA EXCHANGE  

USER REQUIREMENTS AND USE CASE DOCUMENT  

(DRAFT VERSION 0.12)  

|Version: |0.12 |

|Created: |11 June 2009 |

|Last Update: |24 June 2009 |

|Print Date: | |

|By: |AMI ENT ADE Use Case Team |

|Distribution: |Public |

Table of Contents

1.0 Introduction 1

1.1 Introduction to Automated Data Exchange (ADE) 1

1.2 Purpose of Document 2

1.3 Terms and Definitions 2

2.0 Project Business Requirements 2

2.1 Background 2

2.2 Project Opportunity 2

2.3 Project Objectives and Success Criteria 3

2.4 Market Needs 3

2.5 Project Risks 3

2.6 Specific Business Requirements 3

3.0 Project Vision 4

3.1 Project Vision Statement 4

3.2 Major Features 4

3.3 Assumptions and Dependencies 4

4.0 Project Scope 4

4.1 Scope of Initial Release 5

4.2 Scope of Subsequent Releases 5

4.3 Limitations and Exclusions 6

5.0 Project Context 6

5.1 Stakeholder Profiles 6

5.2 Project Priorities 7

5.3 Operating Environment 7

6.0 Project Use Cases 7

6.1 Manage Authorization 8

6.2 Provide Data 9

6.3 Register through 3rd Party Portal 9

6.4 Register through Utility Portal 10

List of Figures

1.0 Introduction

1.1 Introduction to Automated Data Exchange (ADE)

Not only will Smart Grid revolutionize how energy is delivered to consumers, improving reliability and efficiency, it will also change the way consumers manage their energy use, allowing them to participate in the supply through distributed generation such as solar, or indirectly through load reduction during times of peak demand. To help consumers make more economical decisions about energy consumption, new tools must be made available to both the commercial and industrial customers as well as mass market (residential customers). In order for third parties to provide value-added products and services to a wider range of consumers than a traditional utility model, those third parties will need to have access to customer related data, perhaps in an automated fashion. Therefore, the term Automated Data Exchange (ADE) is coined to refer to the ability for third parties to receive customer energy consumption related data, both historical and real-time from utilities that deliver the energy to the consumers.

With the advent of AMI and Smart Grid capabilities, demand side management will be enabled across the board. Not only utilities will provide energy management services, third parties will compete to provide value added services as well, see the diagram on the right.

Today, most of the ongoing AMI programs have components of customer web presentment and portal and third party portal. Depending on the size and nature of the customers (large vs. small, C&I vs. Residential), such customer access capabilities will be different. Third party portal in this context are more for the meter data access from third parties for whom a utility deploys and manages the AMI network and meters.

The broad set of third parties that ADE may need to support over time can be listed as:

• Demand Response (DR) aggregators;

• Retail Service Providers;

• Consumers Energy Management Service and/or Platform providers;

• Third parties for which a utility manages AMI infrastructure and need to have access to meter data and events of their customers.

• Energy Management service providers for future Smart Grid features such as distributed generation, PHEV management, energy storage, etc.

• Other public authorities (PUC, city, etc.) may also be a consumer of ADE data.

From a data perspective, ADE may include the following types of information:

• Consumer energy usage

• Consumer energy management data (demand response program, events, pricing, actions, and notifications.)

• Consumer meter events including power quality, outages, and others.

1.2 Purpose of Document

The Purpose of this Document is to define the vision, scope, and user requirements for an Automated Data Exchange system that permits utilities to share, at the consumer’s request and under the consumer’s direction, usage data with 3rd parties.

1.3 Terms and Definitions

This subsection provides the definition of terms in general use:

|Term |Definition |

|Service Delivery Point (SDP)|Logical point on the network where the ownership of the service changes hands. Used at the place where a meter |

| |may be installed |

2.0 Project Business Requirements

1. Background

Summarize the rational and context for the new project. Provide a general description of the history or situation that led to the decision to initiate this project.

In response to local and federal initiatives toward improving grid reliability and promoting consumer involvement in balancing supply and demand of energy resources, the Open Smart Grid (OpenSG) subcommittee within the UCA International Users Group has organized a number of working groups and task forces to develop requirements and specifications for Smart Grid needs. Among them, the need for Automated Data Exchange (ADE) between utilities and third parties that wish to provide value-added services to consumers has become a high priority. Subsequently, an ad-hoc group has been formed within OpenSG to gather requirements and use cases for ADE from all interested stakeholders, including utilities, 3rd parties, and consumers.

2.2 Project Opportunity

Describe the problem being solved. Include a comparative evaluation of existing projects and potential solutions, indicating why the proposed project is attractive and the advantages it provides. Describe the problems that cannot currently be solved without the project. Show how it aligns with market trends, technology evolution, or strategic directions. Include a brief description of any other technologies, processes, or resources required to provide a complete customer solution.

2.3 Project Objectives and Success Criteria

Summarize the important benefits the project will provide in a quantitative and measureable way. Determine how the stakeholders will define and measure success on this project. State the factors that have the greatest impact on achieving that success, including factors both within and outside the organization’s control. Specify measureable criteria to assess whether the business objectives have been met.

2.4 Market Needs

Describe the needs of typical customers, including needs that current projects or information systems do not meet. Present the problems that customers currently encounter that the new project will address and provide examples of how customers would use the project. Define at a high level any known critical interface or performance requirements, but do not include design or implementation details.

2.5 Project Risks

Summarize the major risks associated with developing – or not developing – the project. Risk categories include marketplace competition, timing issues, user acceptance, implementation issues, and possible negative impacts on the business. Identify any potentially mitigation actions.

2.6 Specific Business Requirements

|REQUIREMENT |

|Ability for a Customer to authorize release of usage data to a 3rd party (either a retailer, aggregator, or registered 3rd party). |

|Ability for a Customer to authorize multiple registered 3rd parties to have limited time based read only access, with a default expiration of|

|6 months, to their usage data |

|Ability for the Customer to actively indicate a specific expiration date or unlimited access timeframe for 3rd party access other than the |

|default of 6 months |

|Ability for the customer to view who which 3rd party(ies) is authorized for read only access to their data, and the expiration date of that |

|access. |

|Ability for the Customer to electronically allow select / revoke which 3rd parties are authorized for read-only access to their data |

|Ability for the utility to accept and store, via a machine to machine interface, a customer attestation from a 3rd party website, indicating |

|that they have granted read only access, to data associated with the customer’s ESIID(s), to that 3rd party. |

| |

|By doing this, the customer will not have to [communicate with the utility] and grant this access to the 3rd party. |

|Ability for a 3rd party to attest [to the utility] that they have a Customer authorization (hardcopy or electronic) authorizing them to read |

|only access the Customer’s data. |

|Ability for 3rd parties and / or Customers to receive a notification when access has been granted, access has been changed, or access has been |

|revoked for an SDP. |

|Ability to provide appropriate level of security depending on who is accessing the SDP data (at the ADE interface). |

|Ability to terminate all users access to premise specific information whenever the TDSP is notified a Customer has moved out of a premise, |

|including any authorization for 3rd party access and permissions to usage history. |

3.0 Project Vision

3.1 Project Vision Statement

Write a concise vision statement that summarizes the long-term purpose and intent of the new project. The vision statement should reflect a balanced view that will satisfy the needs of diverse stakeholders. It can be somewhat idealistic but should be grounds in the realities of existing or anticipated markets, strategic directions, and resource limitations.

3.2 Major Features

Name or number each of the new project’s major features or user capabilities in a unique, persistent way, emphasizing those features that distinguish it from previous or competing projects.

3.3 Assumptions and Dependencies

Record any assumptions that the stakeholders made when conceiving the project and documenting the project vision and scope. Often the assumptions that one party holds are not shared by other parties. If you write them down and review them, you can agree on the project’s basic underlying assumptions. This avoids possible confusion and aggravation in the future. Also, record major dependencies the project has on external factors outside its control.

The following assumptions were made in development of these requirements.

• Third party service providers must be authorized by the utility and/or bonding agency to use the ADE system to get access to utility meter data.

• Consumers must individually authorize 3rd parties to access their data.

• Utilities will provide no customer data (such as address, zip code) through this system. 3rd parties will have their own representation of the user profile. The only association between the two systems is based on the identity (login) of individuals in each system.

• Third parties have the responsibility to manage and protect consumer’s data and privacy in accordance to state and federal regulations.

4.0 Project Scope

4.1 Scope of Initial Release

Summarize the major features that are planned for inclusion in the initial release of the project. If your goals are to focus the standardization effort and to maintain a reasonable project schedule, avoid any temptation to include in release 1.0 every feature that any potential customer might conceivably want someday.

|Feature |In |Out |

|Defining criteria for determining which 3rd Parties are “accredited” (i.e. permitted to access | |X |

|consumption data) within a regulatory region | | |

|Provide a subset of the interface required between a Texas REP and Texas RDP; that is, the ADE interface |X | |

|should be usable for communications of consumption information between and Texas REP and Texas RDP | | |

|Specific 3rd Party presentation of consumer utility data | |X |

|Criteria for Consumer data availability at Utility portal |X | |

|Criteria that PUC uses to assess 3rd Parties’ qualifications | |X |

|Data security, between the utility and 3rd Party |X | |

|Data security, after delivery to 3rd Party | |X |

|Customer consumption data |X | |

|Energy pricing data |X | |

|Other data (e.g. HAN data) | |X |

|All aspects of consumer data in ADE context between utility and 3rd Parties |X | |

|Methods to authorize / revoke 3rd Party access |X | |

|Support for billing mechanisms between utilities and 3rd Parties | |X |

|Specific requirements around auditability | |X |

4.2 Scope of Subsequent Releases

If you envision a staged evolution of the project, indicate which features will be deferred and the desired timing of later releases. Subsequent releases let you implement additional use cases and features and enrich the capabilities of the initial use cases and features.

4.3 Limitations and Exclusions

Defining the boundary between what’s in and what’s out in a way to manage scope creep and customer expectations. List any project capabilities or characteristics that a stakeholder might anticipate but that are not planned for inclusion in the project or in a specific release.

5.0 Project Context

5.1 Stakeholder Profiles

Stakeholders and the individuals, groups, or organizations who are actively involved in a project, are affected by its outcome, or are able to influence its outcome. The stakeholder profiles describe different categories of customers and other key stakeholders for this project. You needn’t describe every stakeholder group, such as legal staff who must check for compliance with pertinent laws. Focus on different types of customers, target market segments, and the different user classes with those segments.

|Stakeholder |Stakeholder Goal |

|Consumer |Vision into ongoing consumption; consumption is “more transparent” |

| |“Well armed”, able to make better choices about their energy consumption |

| |Better / more appropriate services available to them, based upon their consumption |

|Utilities |Additional marketing opportunities |

| |Provide better / more appropriate services to consumers |

| |Can provide additional categories of services, including e.g. Demand Aggregation |

| |“Social” benefit |

| |Required by regulatory agencies / Public Utilities Commision |

| |Increased customer satisfaction. |

| |Standardized interface to 3rd Parties lowers costs |

|3rd Parties |Basic enabler of 3rd Party services |

| |Increases likelihood of utility providing access to consumer data |

| |Simplifies interaction, versus non-standard interface on a per-utility basis |

|PUC |Satisfies PUC role of maximizing consumer value |

| |Lowers utility overall costs |

| |Lowers overall cost of data access implementations |

5.2 Project Priorities

To enable effective decision making, the stakeholders must agree on the project’s priorities. One way to approach this is to consider the five dimensions of a project: features (or scope), quality, schedule, cost, and staff. Each dimension fits in one of the following three categories on any given project:

• A constraint A limiting factor within which the project must operate

• A driver A significant success object with limited flexibility for adjustments

• A degree of freedom A factor that the project has some latitude to adjust and balance against the other dimensions.

The goal is to adjust those factors that are degrees of freedom to achieve the project’s success drivers within the limits imposed by the constraints.

5.3 Operating Environment

Describe the environment in which the system will be used and define the vital availability, reliability, performance, and integrity requirements. This information will significantly influence the definition of the system’s architecture, which is the first – and often the most important – design step.

6.0 Project Use Cases

[pic]

Figure: 1 - ADE - Use Case Diagram

The ADE system is responsible for providing access to a consumer's meter usage data to authorized 3rd party providers.

6.1 Manage Authorization

This processing handles authenticating the consumer user identity upon changes made to registration, expiration, and access settings.

|Responsibilities (external requirements) |

|? |Disallow unauthorized requests (Proposed, Medium difficulty) |

| |The ADE system must allow an administrator to configure the system to allow authorized requests and reject unauthorized requests.|

|? |Manage user identities (Proposed, Medium difficulty) |

| |The ADE system must allow an administrator to configure and/or allow configuration of the system to allow identities to be |

| |created, verified and managed within the system, to prevent unauthorized parties to access the system by using the identity of an|

| |authorized party. |

|? |Protect sensitive information (Proposed, Medium difficulty) |

| |The ADE system must protect sensitive information from inspection and modification by unauthorized parties in transit and at |

| |rest, under all conditions. |

|? |Track all requests (audit) (Proposed, Medium difficulty) |

| |The ADE system must track all requests to allow an administrator or other authorized party to view the history of information |

| |within the system ? when it was created, updated, or deleted, and who performed the action. |

|Constraints |

|? |User has created login accounts for both the utility portal and the 3rd party portal. : (Proposed Pre-condition) |

|? |User has specified to change access to the 3rd party, and has provided identity (login) and password for both domains. : |

| |(Proposed Pre-condition) |

|? |Change to access restrictions made within utility systems and 3rd party systems. : (Proposed Post-condition) |

|Scenarios |

|? |Successful Authorization - Basic Path |

| |Notes |

| | |

| |Portal being used sends authorization request and information to utility (ADE) system. |

| |ADE verifies that both passwords are correct |

| |ADE e-mails a confirmation message to the user (if possible) to verify that they did request the change. |

| |User confirms via e-mail link |

| |ADE stores the authorization change, and notifies utility and 3rd party systems.   |

| | |

|? |Invalid Credentials - Alternate |

| |Notes |

| | |

| |If during basic flow either credential supplied is rejected, notify the user and request for the user to try again. |

| | |

6.2 Provide Data

|Constraints |

|? |3rd Party is registered and configured: (Approved Pre-condition) |

|? |Utility has prepared new data for exchange with 3rd party: (Approved Pre-condition) |

|Scenarios |

|? |Normal Successful Transfer of Data - Basic Path |

| |Notes |

| | |

| |Utility notifies registered 3rd Party that new data is available |

| |3rd Party initiates electronic communication to utility via OpenADE interface, requesting data for registered users |

| |If Utility authenticates 3rd Party identity, and 3rd Party is authorized, Utility system replies with requested data. |

| |If disconnected, 3rd Party may reinitiate connection and resume download of data file. |

| |Utility stores success or failure of each request, with details including client network details, resource requested, date/time, |

| |bytes transferred, and exception details if applicable. |

| | |

|? |Invalid Credentials - Alternate |

| |Notes |

| |At step 3) in the Basic Path, if 3rd Party is not registered, or invalid certificate or other credentials are supplied, or if |

| |authority is not granted, Utility shall reply that access is denied. |

6.3 Register through 3rd Party Portal

This flow allows the consumer to register for a service provided by a 3rd party through the 3rd party portal or website. The flow must provide security measures to prevent unauthorized users from making changes, as well as notify the utility of the change, so that the appropriate user data and messages will be synchronized between the utility and the 3rd party.

|Responsibilities (internal requirements) |

|? |Process enrollments - Functional (Mandatory, Medium difficulty) |

|? |Synchronize subscribing consumer's utility data - Functional (Mandatory, Medium difficulty) |

6.4 Register through Utility Portal

This flow allows the consumer to register for a service provided by a 3rd party through the utility portal or website. The flow must provide security measures to prevent unauthorized users from making changes, as well as notify the 3rd party of the change, so that the 3rd party knows what services have been authorized by each consumer user.

|Responsibilities (internal requirements) |

|? |Provide ability to modify 3rd party provider access - Functional (Proposed, Medium difficulty) |

| |Including viewing a list of 3rd parties having access, ability to revoke access or modify the expiration date of their access. |

|? |Process Enrollments - Functional (Approved, Medium difficulty) |

|Scenarios |

|? |Successful Registration - Basic Path |

| |Notes |

| | |

| |User logs in to utility portal |

| |User views list of registered 3rd parties |

| |User chooses unauthorized 3rd party |

| |User enters 3rd party credentials (login / password) |

| |Utility Portal sends authorization request to 3rd party |

| |3rd party confirms correct credentials and associates utility identity and 3rd party identity |

| |3rd party sends successful result to Utility Portal |

| |Utility Portal notifies ADE |

| | |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download