SG Systems
description
Transcript of SG Systems
McLean VA, May 3, 2010
SG SystemsSG Systems
Systems Requirements Specification Approach Overview
McLean VA, May 3, 2010
SRS Document online
• SG Systems OpenAMI-Ent Shared Documents SRS
McLean VA, May 3, 2010
Topics
• Purpose and Scope• Interoperability Philosophy• Documentation Approach • Guiding Principles• Reference Architecture • Architecture Views
– Business– Application– Data– Technical
McLean VA, May 3, 2010
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).
McLean VA, May 3, 2010
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
ManagementManagement
Meter AssetMeter AssetManagementManagement
AMI NetworkAMI NetworkAssetAsset
ManagementManagement
Representative of AMI-ENT components, not all inclusive.
McLean VA, May 3, 2010
OpenADE Scope
6
McLean VA, May 3, 2010
OpenHAN - Scope
7
AMI Backhaul Network
Load ControlPCT
Plug-In Hybrid Advanced In Home Display
Registere
d Consumer D
evice (S
ecured)
Utility Devic
e
(Secured)
Lighting Control
Smart ApplianceHealth Care
Set Top Box
Consumer D
evice
Distributed Generation
Utility Public
Broadcast
Channel
(Events an
d price s
ignal)
Premise Meter(e.g., Gas)
Premise Electric Meter In Home
Display
Premise EMS
Energy Services Interface
External Interface(Internet)
McLean VA, May 3, 2010
OpenADR – Scope
8
C&I Customer Facility
LOADS
DER
Meter
EMS/Gateway
FacilityManager
Facility/Building Control Network
Residential Customer
HANDevices
DER
Meter
ESI
Customer Home Area Network
EMS/Gateway
AMI Network
AMI Network
Public NetworkPublic
Network
AMI Network
AMI Network
Public NetworkPublic
Network
Utility Enterprise & Operational SystemsUtility Enterprise &
Operational Systems
DMS
HAN-MS
DRMS
CIS
MDMS
AMIHead-End
OpenADRServer
•Consistent OpenADRSemantics based on CIM•Different OpenADR Services (REST, SOAP, SEP2.0, etc.)
McLean VA, May 3, 2010
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
McLean VA, May 3, 2010
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.
McLean VA, May 3, 2010
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.
McLean VA, May 3, 2010
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
McLean VA, May 3, 2010
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 Netw ork 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
McLean VA, May 3, 2010
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»
McLean VA, May 3, 2010
Business View (ADE)act ADE Overv iew
Bond
ing
Auth
ority
3rd
Party
Cons
umer
Utili
ty /
ADE
Register w ith 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
McLean VA, May 3, 2010
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
McLean VA, May 3, 2010
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..*
McLean VA, May 3, 2010
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
McLean VA, May 3, 2010
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
CanceledMeterReading
OrchestrationOrchestration
ServiceService
OperationsOperations
Other interested parties……Guaranteed delivery within ESB, plus internal routing……
ReceiveMeterReading
CreatedMeterReading
ChangedMeterReading
CanceledMeterReading
ReceiveMeterReading
CreatedMeterReading
ChangedMeterReading
CanceledMeterReading
McLean VA, May 3, 2010
• Here is the link to the AMI-ENT SRS v1.0 document (under SRS folder): http://osgug.ucaiug.org/sgsystems/OpenAMIEnt/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.