1 / 27

OpenADE Problem Statement Existing Solutions Standardization Process

OpenADE Problem Statement Existing Solutions Standardization Process Business & User Requirements Overview Request for Participation Q & A. OpenADE Problem Statement. What

macy
Download Presentation

OpenADE Problem Statement Existing Solutions Standardization Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. OpenADE Problem Statement Existing Solutions Standardization Process Business & User Requirements Overview Request for Participation Q & A

  2. OpenADE Problem Statement What • Standardized Machine-to-Machine (M2M) interface that permits utilities to share, at the consumer’s request and under the consumer’s direction, a broad set of that consumer’s utility data with specific 3rd Parties. Who • Consumers! • Utilities (T&D, REPs) • 3rd Parties (Residential Energy Management, Demand Response Aggregators, Distributed Generation, etc.) Why • Increased efficiencies, increased reliability, … (i.e “Why SmartGrid?”) • Standardizes interface: reduces implementation costs, time to market Where • Universal!

  3. Open ADE Problem Statement Existing Solutions Standardization Process Business & User Requirements Overview Request for Participation Q & A

  4. Existing Solutions Currently looking at each of these to elicit business and userrequirements; subsequent efforts (i.e. SRS) will measure each of these against the derived functional requirements, and consider each as a potential technology source. • Proprietary • Existing Utility  3rd Party • Regional • PUCT Implementation Project relating to Advanced Metering • EDI-867

  5. Open ADE Problem Statement Existing Solutions Standardization Process Business & User Requirements Overview Request for Participation Q & A

  6. Standardization Process Historical (through April 2009 OpenSG Meeting) • OpenHAN, others demonstrated successful methodology • NIST and DOE focus on SG interoperable standards • Jurisdictional (e.g. CA, TX) focus on SG interoperable standards • January 2009: OpenSG leadership considers ADE • March 2009: OpenSG leadership request collaboration from leading vendors • April 2009: OpenADE kicked off at OpenSG quarterly meeting

  7. Standardization Process Present Day (April 2009 to July 2009) • Ad Hoc group formed to collect business, user, and functional requirements (roughly equivalent to Use Case Team role) • Meeting weekly via teleconference • Participants (sampling) • Work Product: “OpenADE Business & User Requirements Document”

  8. Standardization Process Futures (July 2009 and forward) • Existing ad hoc team completes gathering business and user requirements, functional requirements • Ad hoc team’s work reviewed by AMI-Ent Use Case team • SRS, Services team (expect some calendar and personnel overlap with requirements team) • Selection of Standards Development Organization (SDO) • Handoff to SDO; expect to continue to work with SDO throughout standardization process

  9. Open ADE Problem Statement Existing Solutions Standardization Process Business & User Requirements Overview Request for Participation Q & A

  10. Requirements Overview OpenADE Business Requirements Business Requirements represent the high-level objectives of the organization in defining the system. Additionally, business requirements help define the domain for the subsequent vision and scope.

  11. Requirements Overview OpenADE Business Requirements Opportunity Objectives and Success Criteria Market Needs Risks Specific Business Requirements

  12. Requirements Overview OpenADE Vision The Project Vision summarizes the project’s long-term purpose and intent. The vision should include all reasonable, eventual goals of the project, not just those targeted for the initial release.

  13. Requirements Overview OpenADE Vision Project Vision Statement: For utility consumers who want greater access to, and derived value from, their utility data … Major Features Standardized interface Data types: consumption, pricing, demand response, HAN Assumptions 3rd Parties must be authorized by the appropriate regulator …

  14. Requirements Overview OpenADE Scope The Project Scope defines a specific release of the project. For a project with anticipated multiple releases, not all features within the project vision might be included in the initial project scope.

  15. Requirements Overview OpenADE Scope OpenADE 1.0 Full implementation of security, authorization requirements Limited to near-realtime and historical consumption data Subsequent Releases Pricing data, utility network events, HAN-related data Limitations and Exclusions

  16. Requirements Overview OpenADE Business Context Business Context summarizes various business issues, including profiles of major stakeholders and the desired relationship between the major project dimensions of scope, quality, schedule, cost and staff.

  17. Requirements Overview OpenADE Business Context Stakeholder Profiles Consumers Utilities 3rd Parties Residential Energy Management C&I Energy Management Demand Response Aggregators REPs (deregulated environments) Project Dimensions Drivers: scope, quality Constraints: schedule Degree of freedom: cost, staff

  18. Requirements Overview OpenADE Use Cases Use Cases can have multiple roles throughout the project life cycle: requirements elicitation, functional requirements, documentation of system design, etc. Use cases employed to elicit user requirements can be less rigorous (i.e. formal) than for other purposes. The following are more properly termed activity diagrams, and are each a high-level graphical representations of the use case scenario.

  19. Requirements Overview “Overview” Use Case

  20. Requirements Overview “Manage Customer Authorization” Use Case

  21. Requirements Overview “Provide Consumer Data” Use Case

  22. Open ADE Problem Statement Existing Solutions Standardization Process Business & User Requirements Overview Request for Participation Q & A

  23. Request for Participation • “Business and User Requirements Document” • AMI-Ent TF > Shared Documents > OpenADE • Breakout Sessions this Afternoon (proposed) • 2:00 to 3:30 – “OpenADE Business and User Requirements” review • 3:45 to 5:00 – “Manage Customer Authorization” Use Case • Weekly Calls • Thursdays 12p to 2p Mountain Time (conflicts with AMI-SEC calls, might have to reschedule) • Email Reflector • Email Dave Mollerstuen (dmollerstuen@tendrilinc.com) to join • Particular need for: • Security-savvy participants • MDMS participants

  24. Open ADE Problem Statement Existing Solutions Standardization Process Business & User Requirements Overview Request for Participation Q & A

  25. Q & A

  26. Thanks!

More Related