AMI Enterprise Task Force of the Utility AMI Working Group

1. AMI Enterprise Task Forceof theUtility AMI Working Group SRS Team Plan Discussion For further information, contact Joe Zhou Team Lead (jzhou@xtensible.net)

2. AMI Enterprise Task Force EPRI MultiSpeak HomePlug & ZigBee IEC TC57 WG14, Other Standards Organizations SCE (Use Cases) Business-Oriented, Common Format Use Cases Use Case Team System Requirements Articulation Service Definitions Team • Integration Requirements • Patterns • Sequence Diagram • Services • WSDL • Recommendations to IEC TC57 WG14: • CIM Extensions • Message Type Updates • System Reqmt Updates http://osgug.ucaiug.org/utilityami/AMIENT

3. SRS Team • Goal: Generate System Requirements Specification (SRS) • Team Leader: Joe Zhou(jzhou@xtensible.net) • Similar scope and coverage as SRS created by Utility AMI WG’s OpenHAN TF. Include the following topics: • A discussion of the reasons the Utility members of the AMI-Ent will undertake this work • Includes a glossary of terms   • Guiding Principles and the System Architecture • Includes an assessment of the IEC61968 Interface Reference Model (IRM) as a means for organizing information exchange requirements among utility business functions.   • A list system requirements not necessarily covered by business use cases.   • This document would lay the foundation on which independent use cases and services would be defined. • First Step: Assess IEC 61968 standards to determine gaps between the standard and what is needed for AMI-Enterprise scope. Make recommendations to fill gaps.

4. What is Software Architecture? • Software architecture is a result of technical, business, and social influences. The existence of the software architecture in turn affects the technical, business, and social environments that subsequently influence future architectures. • Architecture stakeholders are: • Customer • End user • Sales and marketing • Competitor/Market • Development organization • Maintenance • There is no such thing as an inherently good or bad architecture. Architectures are either more or less fit for some stated purposes. Source: Software Architecture in Practice

5. Architecture Quality Attributes – Design Criteria • System quality attributes discernable at runtime • Performance, Security, Availability, Functionality, Usability, Scalability • System quality attributes NOT discernable at runtime • Modifiability, Portability, Reusability, Integrability, Testability • Business Qualities • Time to market; Cost; Projected life time of the system; Targeted market; Rollout schedule; Extensive use of legacy system • Qualities directly related to the architecture • Conceptual integrity; Correctness and completeness; Buildability Source: Software Architecture in Practice

6. GridWise Interoperability Context-Setting Framework

7. AMI-Ent SRS • AMI-Ent SRS is a system requirements specification for how GridWise Interoperability Context-Setting Framework can be applied for AMI enterprise integration using well defined architectural practice. • SRS Table of Content • Introduction • Guiding Principals • Architecture Considerations • AMI-Ent Functions and Logical Systems • AMI-Ent Requirements • Refer to integration requirements from the Service Definition Team • Develop a list of requirements that are not covered by the above • AMI-Ent Glossary of terms and definitions

8. AMI-Ent SRS Next Steps • Develop and agree on the initial scope (Table of Content) • Develop the following: (things are needed for other teams right away) • Glossary of terms and definitions • Guiding principals • AMI-Ent functional and logical systems model (leverage IEC 61968) • Develop AMI-Ent requirements • Address GridWise Interoperability Framework component as they apply to AMI-Ent • Address the rest of architectural requirements not covered by the Framework • Refer to other standards where they apply, identify gaps where exist. • Develop, review and finalize AMI-Ent SRS document for public comment