SG Systems - PowerPoint PPT Presentation

About This Presentation
Title:

SG Systems

Description:

SG Systems Systems Requirements Specification Approach Overview * * * * To provide a list of Logical Components and the integration services they either provide or ... – PowerPoint PPT presentation

Number of Views:48
Avg rating:3.0/5.0
Slides: 21
Provided by: osgugUcai7
Learn more at: http://osgug.ucaiug.org
Category:

less

Transcript and Presenter's Notes

Title: SG Systems


1
SG Systems
  • Systems Requirements Specification Approach
    Overview

2
SRS Document online
  • SG Systems ? OpenAMI-Ent ? Shared Documents ? SRS

3
Topics
  • Purpose and Scope
  • Interoperability Philosophy
  • Documentation Approach
  • Guiding Principles
  • Reference Architecture
  • Architecture Views
  • Business
  • Application
  • Data
  • Technical

4
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
AMI-ENT Scope
6
OpenADE Scope
6
7
OpenHAN - Scope
7
8
OpenADR Scope
8
9
Semantic Interoperability
10
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
Guiding Principles
Name Description
1 Utility 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.
2 Business driven architecture and design Requirements and architecture patterns and designs of this effort shall be driven by real world business requirements of AMI.
3 Open interoperability The 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.
4 Leverage 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.
5 Actionable, 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
6 Platform Independence Requirements and design artifacts shall be platform independent. Implementation technologies shall be chosen due to its level of acceptance at the marketplace as open standards.
7 Common 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.
8 Common Information Model Common definition of meanings and relationships of how to represent information that are often context dependent.
9 Extensibility This 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.
 mjz1AEP 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.  mjz2AEP 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.  mjz3AEP 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.
12
AMI-ENT Reference Architecture
13
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
Business View (DR)
15
Business View (ADE)
16
Application View
17
Data View
18
Technical View (Components)
19
Technical View (Patterns)
20
Contact Info.
  • Here is the link to the AMI-ENT SRS v1.0 document
    (under SRS folder) http//osgug.ucaiug.org/sgsyst
    ems/OpenAMIEnt/Shared20Documents/Forms/AllItems.a
    spx
  • If you have comments and/or wish to join and
    contribute to the AMI-ENT SRS effort, please
    contact Joe Zhou at jzhou_at_xtensible.net
Write a Comment
User Comments (0)
About PowerShow.com