SG Systems
Systems Requirements Specification
Approach Overview
San Francisco, March, 2011
SRS Document online
• SG Systems  OpenAMI-Ent  Shared
Documents  SRS
San Francisco, March, 2011
Topics
•
•
•
•
•
•
Purpose and Scope
Interoperability Philosophy
Documentation Approach
Guiding Principles
Reference Architecture
Architecture Views
–
–
–
–
Business
Application
Data
Technical
San Francisco, March, 2011
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).
San Francisco, March, 2011
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.
San Francisco, March, 2011
OpenADE Scope
6
San Francisco, March, 2011
OpenHAN - Scope
)
D
red
cu
Ge istrib
Se
ne
(
e
rat uted
vic
ion
Plu
De
r
g-I
me
nH
u
s
n
yb
rid
Co
A
Ho dvan
red
me ce
iste
g
d
Dis In
Re
pla
Lo
y
ad
Co
ntr
ol
PC
T
Ele Pre
ctr mis
ic M e
ete
r
Pre
m
(e. ise M
g.,
Ga eter
s)
AM
IB
ac
kh
au
lN
etw
ork
En
erg
yS
erv
ice
s In
ter
fac
e
e
vic
De )
ity ured
il
t
U ec
(S
Ex
ter
na
(In l Inte
ter
ne rface
t)
Pre
mis
eE
MS
In
Dis Hom
pla e
y
Se
tT
Lig
Co hting
ntr
ol
He
alth
Ca
re
S
Ap mar
plia t
nc
e
op
Bo
x
ice
ev
rD
e
m
nsu
Co
l
ne
an
Ch l)
t
as na
dc e sig
oa
Br pric
c
li
d
b
n
Pu ts a
n
ity
Util (Eve
7
San Francisco, March, 2011
OpenADR – Scope
C&I Customer Facility
LOADS
DMS
EMS/Gateway
DER
Meter
HAN-MS
AMI
Head-End
Public
Public
Network
Network
Facility
Manager
Facility/Building
Control Network
DRMS
CIS
OpenADR
Server
AMI
AMI
Network
Network
Residential Customer
EMS/
Gateway
ESI
MDMS
Utility Enterprise &
Utility Enterprise &
Operational Systems
Operational Systems
HAN
Devices
DER
•Consistent OpenADR
Semantics based on CIM
•Different OpenADR Services
(REST, SOAP, SEP2.0, etc.)
Meter
Customer
Home Area
Network
8
San Francisco, March, 2011
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
San Francisco, March, 2011
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.
San Francisco, March, 2011
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.
San Francisco, March, 2011
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
San Francisco, March, 2011
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
San Francisco, March, 2011
Business View (DR)
San Francisco, March, 2011
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
San Francisco, March, 2011
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
ScheduledEvent
Created
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
ServiceToken
Created
Changed
MeterSystemEvent
BillingDeterminant
MeterAssetRequest
MeterServiceOrderRequest
Create
Change
Create
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
San Francisco, March, 2011
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
San Francisco, March, 2011
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
San Francisco, March, 2011
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……
San Francisco, March, 2011
Contact Info.
•
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
•
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
San Francisco, March, 2011