knoxville, tn oct. 19, 2009 ami-enterprise systems requirements specification overview

Knoxville, TN Oct. 19, 2009

AMI-EnterpriseAMI-Enterprise

Systems Requirements Specification Overview


Topics

• Purpose and Scope• Interoperability Philosophy• Documentation Approach • Guiding Principles• Reference Architecture • Architecture Views

– Business– Application– Data– Technical


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.

• The scope of AMI-ENT 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).


AMI-ENT Scope

AMIAMI--ENTENT

Enterprise Bus + Common Model & Service

Outage Outage ManagementManagement

CustomerCustomerInfo. & BillingInfo. & Billing

Revenue Revenue ProtectionProtection

DistributionDistributionManagementManagement

AMI ServiceAMI ServiceManagerManager

HANHANManagementManagement

Third PartyThird PartyPortalPortal

CustomerCustomerPortalPortal

MeterMeterDataData

ManagementManagement

DemandDemandResponseResponse


Meter AssetMeter AssetManagementManagement

AMI NetworkAMI NetworkAssetAsset


Representative of AMI-ENT components, not all inclusive.


Semantic Interoperability

Application Layer

Integration Layer

Business Process and Intelligence LayerBusiness Modeling & Design Layer

BusinessLogic

Data

Interface

GUI

BusinessLogic

Data

Interface

GUI

BusinessLogic

Data

Interface

GUI

Business Process Models

InformationServiceModel

Enterprise Semantic Model

Mapping to Application Metadata, and Industry

Standards

Industry Standards

InterfaceMetadata

TransformTo

ExecutableProcesses

TransformTo

ExecutableServices/

Messages/Data Models

Enterprise Services Bus

Enterprise Data Integration

Enterprise ETL

(Transformation Logic)

Business Process Management

B2B Business Intelligence

(Common Business Terms & Semantics)

DM/DW

TransformationCommon Semantic


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.


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.


AMI-ENT Reference Architecture

AMI Customer Facing ComponentsAMI Customer Facing Components

AMI Edge AMI Edge ComponentsComponents Utility Operations and Enterprise Analysis ComponentsUtility Operations and Enterprise Analysis Components

Process Integration PlatformProcess Integration Platform

Information Management PlatformInformation Management Platform

Federated Federated ESBsESBs + ESM+ ESM

EII/EDI/ETL + ESMEII/EDI/ETL + ESM

MetadataRepository

ServiceManagement

SecurityManagement

ProcessOrchestration

Monitoring &Management

Data Warehouse& Data Mart

Reporting& Analysis

AMI SpecificComponents

AMI Head End #n

DemandResponse

Command & Control

AMIService Manager

AMI Head End #2

AMI Head End #1

AMI Meter Asset

Maintenance

Utility Operations and EnterpriseUtility Operations and EnterpriseComponentsComponents

AMI NetworkAsset

Maintenance

C&I DemandResource

Management

AMINetwork

Management

CustomerInformation

Analysis

Customer Information

Management

CustomerPresentment &

Analysis (C&I)

CustomerPresentment &

Analysis (Residential)

Customer RelationshipManagement

DistributionEngineering

Analysis

DistributionManagement

DistributionOperational

Analysis

DemandResponse

Management

DistributionSCADA

Enterprise AssetManagement

EnergyManagement

GeographicInformation

Management

Home AreaNetwork

Management

Meter DataManagement

Work and MobileManagement

OutageManagement

Power Trading

RevenueProtection

Supply ChainManagement

TransformerLoad Management

Third PartyPortal

Meter DataAnalysis

CustomerPortal

ComplexEvent Processing

Real TimeBI


Business View (AMI)

uc B1 - Meter Reading

B1 - Meter Reading

B1 - Scenario 1 - AMI Meter completes scheduled read

request B1 - Scenario 2 - AMI Meter completes an on-demand

read

B1 - Scenario 3 - AMI Meter transmits non-usage (ev ent)

messages

B1 - Scenario 5 - Data users successfully retriev e either raw or bill ready usage data

B1 - Scenario 6 - AMI Head End manages the meter reading

schedule

B1 - Scenario 7 - Third party accesses AMI data

B1 - Scenario 8 - Third Party uses Utility's AMI Network to

read their meters

B1 - Scenario 9 - Meter does not communicate remotely during default

schedule read «trace»

«trace»

«trace»

«trace»«trace»

«trace»

«trace»

«trace»

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


Business View (DR)

class Business Process Model

Manage Demand for Grid Reliability

Customer

Energy Shortage/Congestion/Equipment

Failure

«goal»Maintain Reliability of

the Grid

Load Control Transaction

ISO

(from Actors)

Supply Profile

Compliance

Distributor

(from Actors)

Demand Response Prov ider

(from Actors)

Manage Demand for Economic Dispatch

«goal»Achiev e Least Cost

Dispatch

Automatic Generation Control

(AGC)

Spinning Reserv es Non-spinning Reserv es

Replacement Reserv es

Market condition that forces either buying more energy at significant cost or reduce

demand to avoid the buy

Load Control Transaction Sufficient to Av oid Buying Energy

«uses»

«supply»

«signal» «load» «uses»

«signal»

«load»«signal»

«flow» «flow» «flow» «flow»

«signal»


Business View (ADE)act ADE Ov erv iew

Bo

nd

ing

Au

tho

rity

3rd

Pa

rty

Co

ns

um

er

Uti

lity

/ A

DE

Register with Utility

Process 3rd PartyApplications

Start

Screen 3rd PartyApplicant Approved?

Configure 3rd Party inADE

End

Register for 3rd PartyServ ice

Prov ide RegisteredUsers Usage Data to

3rd Parties

Receiv e UsageData

View Usage v ia3rd Party

Track and SettleCosts and Usage

Process UserRegistration

yes

no

Draft


Application View

Services Provided/Consumed by “Customer Information Management”

Customer Information ManagementCustomer Information Management

Meter Data ManagementMeter Data Management

AMI Head EndAMI Head End

Meter Data ManagementMeter Data Management

AMI Head EndAMI Head End

Create

Created

Created

CreatedCommonConfirmation

MeterStatus

HanAsset

BillingDeterminant

MeterStatus

MeterSystemEvent

Service Consumers Service Providers

ScheduledEvent

ConnectDisconnect

CommonConfirmation

MeterStatusCreated

Created HANAsset

BillingDeterminant

MeterStatus

MeterSystemEvent

ScheduledEvent

ConnectDisconnect

CreateMeterStatusRequest MeterStatusRequest

CreateLoadControlCommandRequest LoadControlCommandRequest

CreatedServiceToken ServiceToken

CreateHANAsset HANAsset

CreateBillingDeterminant BillingDeterminant

ChangeMeterAssetRequest MeterAssetRequest

CreateMeterServiceOrderRequest MeterServiceOrderRequest

Service Providers / Consumers

Service Operation

Created

Created

Service Operation

Changed

Microsoft PowerPoint Presentation


Data View

class Meter Reading and Ev ent

MeterReading ComFunction

Reading

ReadingQuality Interv alReading

Interv alBlock

ReadingType

MeterAsset

Activ ityRecord

EndDev iceEv ent

MeterSystemEv ent

Dev iceFunction

TimeSchedule

TimePoint

ScheduledEv ent

ScheduleParameters

Tok en Transaction

PointOfSale0..* 0..1

0..*

0..*

0..*

0..* 1

0..*

0..*

0..*

0..* 1.. * 1.. * 0..*

0..1

0..*

1

0..*

0..1

0..*

0..*

0..1

1

0..1

1

0..*

1

0..1

1 0..1

0..1

0..*

0..*0..* 0..* 0..*0..*

0..*


Technical View (Components)

Process Integration PlatformProcess Integration Platform

Information Management PlatformInformation Management Platform

Federated Federated ESBsESBs + ESM+ ESM

EII/EDI/ETL + ESMEII/EDI/ETL + ESM

MetadataRepository

ServiceManagement

SecurityManagement

ProcessOrchestration

Monitoring &Management

Data Warehouse& Data Mart

Reporting& Analysis

ComplexEvent Processing

Real TimeBI


Technical View (Patterns)

Application A Transparent ESB

ANativeAPI or Service

T S/C

Application B

BNativeAPI or Service

TS/PS/P S/C

SendMeterReading

CreatedMeterReading

ChangedMeterReading

CanceledMeterReading

SendMeterReading

CreatedMeterReading

ChangedMeterReading


OrchestrationOrchestration

ServiceService

OperationsOperations

Other interested parties……Guaranteed delivery within ESB, plus internal routing……

ReceiveMeterReading

CreatedMeterReading

ChangedMeterReading


ReceiveMeterReading

CreatedMeterReading

ChangedMeterReading



• Here is the link to the AMI-ENT SRS v1.0 document (under SRS folder): http://osgug.ucaiug.org/utilityami/AMIENT/Shared%20Documents/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 [email protected]

Contact Info.

knoxville, tn oct. 19, 2009 ami-enterprise systems requirements specification overview

Documents

business architecture

business driven architecture

data architecture

application architecture

logical business applications

architecture patterns

architecture domains

technology architecture