1. McLean VA, May 3, 2010 SG Systems Systems Requirements Specification Approach Overview

2. McLean VA, May 3, 2010 SRS Document online SG Systems  OpenAMI-Ent  Shared Documents  SRS

3. McLean VA, May 3, 2010 Topics Purpose and Scope Interoperability Philosophy Documentation Approach Guiding Principles Reference Architecture Architecture Views –Business –Application –Data –Technical

4. McLean VA, May 3, 2010 Purpose and Scope The purpose of this document is to provide the architecture vision and requirements to serve as the “rules of engagement” for how vendors and utilities could implement recommended requirements and design specifications. Mainly focus on the AMI-ENT which is about how applications within the utility enterprise are to be integrated and composed to support AMI related business processes and functions. It is to deal with inter-application related business functions and stops at the boundaries of applications and the edge of utility enterprise. Edge applications are those applications that communicate with networks and devices in the field, as well as those that communicate with other businesses or enterprises (generally defined as third parties).

5. McLean VA, May 3, 2010 AMI-ENT Scope

6. McLean VA, May 3, 2010 OpenADE Scope 6

7. McLean VA, May 3, 2010 OpenHAN - Scope 7

8. McLean VA, May 3, 2010 OpenADR – Scope 8

9. McLean VA, May 3, 2010 Semantic Interoperability

10. McLean VA, May 3, 2010 Documentation Approach According to The Open Group, there are four architecture domains that are commonly accepted as subsets of an overall enterprise architecture, all of which TOGAF is designed to support: –The Business Architecture defines the business strategy, governance, organization, and key business processes. –The Data Architecture describes the structure of an organization's logical and physical data assets and data management resources. –The Application Architecture provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization. –The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.

11. McLean VA, May 3, 2010 Guiding Principles [mjz1] {AEP} Something should be said about companies' tendency to overestimate their differentiators. After all, a utility-driven process is the default and results in everybody rolling their own. [mjz1] [mjz2] {AEP} Standards that are almost, but not quite, good enough may be worse than no standard at all. The key is knowing HOW to build upon a standard (and knowing how to build a standard that can be built upon). This is something that a lot of people think is obvious and easy. It's...not.[mjz2] [mjz3] {AEP} The phrase "common information model" is here used in its plain-English sense, but it is also the name of a body of standards, inviting confusion.[mjz3] #NameDescription 1Utility driven and open process The process for developing, reviewing and ratifying the AMI-ENT specifications and artifacts including the SRS should be driven by utilities and contributed to by vendors. It shall be open to all members of UCAIug. 2Business driven architecture and design Requirements and architecture patterns and designs of this effort shall be driven by real world business requirements of AMI. 3Open interoperabilityThe IEEE defines interoperability as: the ability of two or more systems or components to exchange information and to use the information that has been exchanged. A complete interoperable solution requires systems or components to interoperate at both the technical and semantic levels. 4Leverage and collaborate with industry standards Where relevant industry standards exist to provide references, best practices, existing work products, and future directions, they should be leveraged to reduce time and increase quality of this effort. 5Actionable, testable and transferable work products Any work (artifacts) that are created can be used by the audience for this work, e.g. utilities, vendors, regulators, etc. There needs to be clear, explicit guidance for how to use the artifacts. There is an expectation that the work products are useful at lower levels of design 6Platform IndependenceRequirements and design artifacts shall be platform independent. Implementation technologies shall be chosen due to its level of acceptance at the marketplace as open standards. 7Common and Logical Reference Model Common components with known definitions that can be agreed upon; that they contain a common functionality that can be defined. This may be organized as logical business applications; there is an understanding of what applications will provide/consume what services. 8Common Information Model Common definition of meanings and relationships of how to represent information that are often context dependent. 9ExtensibilityThis activity will prioritize functions with a focus on AMI functions, but does not preclude future extensions of the architecture; e.g. smart grid. Implementation of AMI will also vary from utility to utility.

12. McLean VA, May 3, 2010 AMI-ENT Reference Architecture

13. McLean VA, May 3, 2010 Business View (AMI) Business Processes: B1 - Meter Reading B2 - Remote Connect/Disconnect B3 - Detect Theft B4 - Contract Meter Reading Consolidated Demand Response and Load Control C1 - Price Based DR and Voluntary Load Control C2 - Customer Views Energy Data C3 - Prepayment C4 - Third Parties Use AMI Network D2 - Distribution Automation D3 - Distributed Generation D4 - Outage Location and Restoration G1 - Gas System Measurement G2 - Gas System Planning G3 - Gas System Corrosion Control I1 - AMI System Installation I2 - AMI System Life-cycle Management I3 - Utility Updates AMI System S1 - AMI System Recovery

14. McLean VA, May 3, 2010 Business View (DR)

15. McLean VA, May 3, 2010 Business View (ADE) Draft

16. McLean VA, May 3, 2010 Application View

17. McLean VA, May 3, 2010 Data View

18. McLean VA, May 3, 2010 Technical View (Components)

19. McLean VA, May 3, 2010 Technical View (Patterns)

20. McLean VA, May 3, 2010 Here is the link to the AMI-ENT SRS v1.0 document (under SRS folder): http://osgug.ucaiug.org/sgsystems/OpenAMIEnt/Shared%20Doc uments/Forms/AllItems.aspx http://osgug.ucaiug.org/sgsystems/OpenAMIEnt/Shared%20Doc uments/Forms/AllItems.aspx If you have comments and/or wish to join and contribute to the AMI-ENT SRS effort, please contact Joe Zhou at jzhou@xtensible.net jzhou@xtensible.net Contact Info.