Transcript AMI-Enterprise Systems Requirements Specification Overview Knoxville, TN Oct. 19, 2009 Topics • • • • • • Purpose and Scope Interoperability Philosophy Documentation Approach Guiding Principles Reference Architecture Architecture Views – – – – Business Application Data Technical Knoxville, TN Oct.

AMI-Enterprise
Systems Requirements Specification
Overview
Knoxville, TN Oct. 19, 2009
Topics
•
•
•
•
•
•
Purpose and Scope
Interoperability Philosophy
Documentation Approach
Guiding Principles
Reference Architecture
Architecture Views
–
–
–
–
Business
Application
Data
Technical
Knoxville, TN Oct. 19, 2009
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).
Knoxville, TN Oct. 19, 2009
AMI-ENT Scope
Customer
Info. & Billing
Outage
Management
Distribution
Management
Revenue
Protection
HAN
Management
AMI Service
Manager
Enterprise Bus + Common Model & Service
AMIAMI-ENT
Demand
Response
Management
Customer
Portal
Third Party
Portal
Meter
Data
Management
AMI Network
Asset
Management
Meter Asset
Management
Representative of AMI-ENT components, not all inclusive.
Knoxville, TN Oct. 19, 2009
Semantic Interoperability
Business Modeling & Design Layer
Business
Process
Models
Transform
To
Executable
Processes
Information
Service
Model
Transform
To
Executable
Services/
Messages/
Data Models
Business Process and Intelligence Layer
Business Process
Management
B2B
Business Intelligence
Integration Layer
Enterprise Services
Bus
Enterprise Data
Integration
Enterprise
ETL
DM/DW
Enterprise Semantic Model
(Common Business Terms &
Semantics)
Application Layer
Mapping to Application
Metadata, and Industry
Standards
GUI
GUI
GUI
(Transformation Logic)
Business
Logic
Industry
Standards
Common Semantic
Interface
Metadata
Data
Interface
Business
Logic
Data
Interface
Business
Logic
Interface
Data
Transformation
Knoxville, TN Oct. 19, 2009
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.
Knoxville, TN Oct. 19, 2009
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.
Knoxville, TN Oct. 19, 2009
AMI-ENT Reference Architecture
Customer
Presentment &
Analysis
(C&I)
Customer
Presentment &
Analysis
(Residential)
AMI Meter
Asset
Maintenance
AMI Network
Asset
Maintenance
Third Party
Portal
Customer
Portal
C&I Demand
Resource
Management
Demand
Response
Management
Home Area
Network
Management
Meter Data
Management
AMI
Head End #1
AMI
Head End #2
AMI Customer Facing Components
Revenue
Protection
Process Integration Platform
AMI
Head End #n
Process
Orchestration
Complex
Event Processing
Monitoring &
Management
AMI Specific
Components
Federated ESBs + ESM
Demand
Response
Command & Control
Metadata
Repository
Service
Management
Security
Management
EII/EDI/ETL + ESM
AMI
Service
Manager
AMI
Network
Management
AMI Edge
Components
Data Warehouse
& Data Mart
Real Time
BI
Customer
Information
Management
Customer
Relationship
Management
Distribution
Management
Distribution
SCADA
Enterprise Asset
Management
Energy
Management
Geographic
Information
Management
Work and Mobile
Management
Outage
Management
Power Trading
Supply Chain
Management
Transformer
Load Management
Reporting
& Analysis
Information Management Platform
Customer
Information
Analysis
Distribution
Engineering
Analysis
Distribution
Operational
Analysis
Meter Data
Analysis
Utility Operations and Enterprise Analysis Components
Utility Operations and Enterprise
Components
Knoxville, TN Oct. 19, 2009
Business View (AMI)
Business Processes:
B1 - Meter Reading
uc B1 - Meter Reading
B2 - Remote Connect/Disconnect
B1 - Scenario 1 - AMI Meter
completes scheduled read
request
B3 - Detect Theft
B1 - Scenario 2 - AMI Meter
completes an on-demand
read
B4 - Contract Meter Reading
Consolidated Demand Response and Load Control
C1 - Price Based DR and Voluntary Load Control
B1 - Scenario 9 - Meter
does not communicate
remotely during default
schedule read
«trace»
«trace»
C2 - Customer Views Energy Data
C4 - Third Parties Use AMI Network
D2 - Distribution Automation
B1 - Scenario 3 - AMI Meter
transmits non-usage (ev ent)
messages
«trace»
C3 - Prepayment
«trace»
B1 - Scenario 8 - Third Party
uses Utility's AMI Netw ork to
read their meters
B1 - Meter Reading
«trace»
D3 - Distributed Generation
«trace»
«trace»
D4 - Outage Location and Restoration
«trace»
G1 - Gas System Measurement
G2 - Gas System Planning
G3 - Gas System Corrosion Control
B1 - Scenario 7 - Third party
accesses AMI data
B1 - Scenario 6 - AMI Head End
manages the meter reading
schedule
B1 - Scenario 5 - Data users
successfully retriev e either
raw or bill ready usage data
I1 - AMI System Installation
I2 - AMI System Life-cycle Management
I3 - Utility Updates AMI System
S1 - AMI System Recovery
Knoxville, TN Oct. 19, 2009
Business View (DR)
Knoxville, TN Oct. 19, 2009
Business View (ADE)
Draft
act ADE Ov erv iew
Process 3rd Party
Applications
Configure 3rd Party in
ADE
Prov ide Registered
Users Usage Data to
3rd Parties
Track and Settle
Costs and Usage
yes
Register for 3rd Party
Serv ice
Process User
Registration
Register w ith Utility
View Usage v ia
3rd Party
Receiv e Usage
Data
Start
Screen 3rd Party
Applicant Approved?
no
End
Knoxville, TN Oct. 19, 2009
Application View
Services Provided/Consumed by “Customer Information Management”
Service Operation
CommonConfirmation
MeterStatus
HanAsset
Created
Created
Created
Service Operation
CommonConfirmation
MeterStatus
MeterSystemEvent
Meter Data Management
Meter Data Management
Created
Created
Created
Created
ScheduledEvent
MeterStatus
ConnectDisconnect
Create
ConnectDisconnect
HANAsset
MeterStatusRequest
Create
MeterStatusRequest
LoadControlCommandRequest
Create
LoadControlCommandRequest
HANAsset
Create
HANAsset
AMI Head End
AMI Head End
BillingDeterminant
ScheduledEvent
BillingDeterminant
MeterStatus
ServiceToken
Created
Changed
MeterSystemEvent
BillingDeterminant
MeterAssetRequest
MeterServiceOrderRequest
Create
Change
Create
ServiceToken
AMI Head End
AMI Head End
BillingDeterminant
MeterAssetRequest
MeterServiceOrderRequest
Meter Data Management
Meter Data Management
Customer Information Management
Customer Information Management
Service Consumers
Service Providers / Consumers
Service Providers
Knoxville, TN Oct. 19, 2009
Data View
class Meter Reading and Ev ent
Activ ityRecord
0..*
1
MeterSystemEv ent
MeterAsset
0..*
Tok en
0..*
0..*
0..*
ScheduledEv ent
EndDev iceEv ent
1
0..*
1
0..1
ScheduleParameter s
0..*
0..*
MeterReading
0..1
ComFunction
0..*
0..*
0..1
Dev iceFunction
1
Transaction
0..*
0..1
0..1
0..*
PointOfSal e
0..1
0..*
0..*
0..*
Reading
Interv alBlock
0..*
1.. *
1.. *
0..*
0..*
ReadingType
0..10..1
TimeSchedule
0..*
0..*
ReadingQuality
Interv alReading
0..*
1
1
0..*
TimePoint
Knoxville, TN Oct. 19, 2009
Technical View (Components)
Process Integration Platform
Process
Orchestration
Complex
Event Processing
Monitoring &
Management
Federated ESBs + ESM
Metadata
Repository
Service
Management
Security
Management
EII/EDI/ETL + ESM
Data Warehouse
& Data Mart
Real Time
BI
Reporting
& Analysis
Information Management Platform
Knoxville, TN Oct. 19, 2009
Technical View (Patterns)
SendMeterReading
Service
Operations
A
Native
API or
Service
T
S/C
Application A
S/P
ReceiveMeterReading
CreatedMeterReading
CreatedMeterReading
ChangedMeterReading
ChangedMeterReading
CanceledMeterReading
CanceledMeterReading
Orchestration
Transparent ESB
Guaranteed delivery within ESB,
plus internal routing……
S/C
S/P
T
Native
API or
Service
B
Application B
Other interested parties……
Knoxville, TN Oct. 19, 2009
Contact Info.
•
Here is the link to the AMI-ENT SRS v1.0 document (under SRS
folder):
http://osgug.ucaiug.org/utilityami/AMIENT/Shared%20Document
s/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]
Knoxville, TN Oct. 19, 2009