AMI-EnT TF - System Requirements Specification - Version 1 - Oct142009 (1)

8/12/2019 AMI-EnT TF - System Requirements Specification - Version 1 - Oct142009 (1)

1/59

UtilityAMI AMI-ENT Task ForceUtilityAMI AMI-ENT System Requirements Specification

UtilityAMI AMI-ENT System Requirements Specification

Version: v1.0

Release Date: October 14, 2009

Draft v1.0, Oct. 14, 2009 Page 1 of 59

Copyri !t "##$% UtilityAMI% All Ri !ts Reser&e'

12

1

2

3

4

5

6

7

8

9

1011121314

151617181920212223

24252627

3

4


2/59


Ackno(le' ementsThe following individuals and their companies are mem ers of the !"#iug $pen%& and havecontri uted and'or provided support to the wor( of the !tilit)#*+ #*+,-.T %)stem /e uirements%pecification

&erald &ra) from "onsumers -nerg)

*ar( onfinglo from -nterg)

*ar( $rti from "onsumers -nerg)

%hawn u from tensi le %olutions

ohn *ani from "omverge

iaofeng ang from &-

/on arson from &-

/and) owe from #-

:ran( ilhoit from #-

.eil &reenfield from #-

%teve eimlich from /osewood %)stems

;ouglas ouseman from "apgemini

a)ne ongcore from "onsumers -nerg)

&reg /o inson from tensi le %olutions

Terr) *ohn from %an ;iego &as < -lectric

=a) %tefferud from oc(e *artin

oe >hou from tensi le %olutions

The #*+,-.T Tas( :orce wishes to than( all of the a ove,mentioned individuals and their companiesfor their support of this important endeavor? as it sets a (e) foundation for interopera le %mart &rid of thefuture@



12

1

234

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22232425

3

4


3/59


)ocument *istory

Re&ision *istory;ate of this revision $ct@ 14? 2009

RevisionNumber

Revision Date RevisionBy

Summary of Changes Changesmarked

0@1 :e 122009 oe >hou %/% initial draft created@ .0@2 :e 242009 oe >hou #ggregated comments from mem ers of %/% to

version 0@1 .

0@3 #pril082009 oe >hou !pdated the document structure and content asedupon v0@1 comments and edits from mem ers of%/% team? changed document structure to focus on

potential re uirements areas of the architecture

views@

.

0@4 ul)092009 oe >hou !pdated document ac( on feed ac( on edits andadded securit) related re uirement considerationsAsection 2@4B@

.

1@0 $cto er142009 oe >hou *inor updates per comments received .

+pen Issues ,o

ast updated :e @ 12? 2009

IssueNumber

Issue Date ProvidedBy

Summary of the Issue



12

1

2

34

5

67

8

3

4


4/59


Contents1. Introduction....................................................................................................................6

1.1 Purpose.............................................................................................................................................. 6

1.2 Scope.................................................................................................................................................1.3 !cron"#s and !$$reviations..............................................................................................................%

1.4 &'terna( )onsiderations and *eferences...........................................................................................9

1.5 Docu#ent Overvie+........................................................................................................................... 9

2. !rc itecture Overvie+ .................................................................................................111.6 !rc itecture -ision........................................................................................................................... 11

1. !rc itecture uiding Princip(es........................................................................................................ 15

1.% !rc itectura( )onsiderations............................................................................................................ 1

1.9 Securit" )onsiderations.................................................................................................................. . 1

1.10 !/I & *eference /ode(............................................................................................................ 22

3. !/I & S"ste#s !rc itecture ..................................................................................21.11 !/I & usiness !rc itecture -ie+............................................................................................ 2

1.11.1 Integration *e uire#ents ra#e+or ......................................................................................2

1.11.2 usiness !rc itecture )o#ponents......................................................................................... 2%

1.12 Integration *e uire#ents Specification..........................................................................................33

1.12.1 unctiona( *e uire#ents 7 usiness Processes.....................................................................33

1.12.2 unctiona( *e uire#ents 7 Integration Services..................................................................... 3

1.12.3 ec nica( *e uire#ents 7 Integration Services.......................................................................421.13 !/I & !pp(ication !rc itecture -ie+......................................................................................... 44

1.14 !/I & Data !rc itecture -ie+................................................................................................... 46

1.14.1 /eter *eading and &vent -ie+......................................................................................... ...... 46

1.14.2 !sset and )usto#er Infor#ation -ie+.....................................................................................4

1.14.3 &nd Device )ontro( -ie+.........................................................................................................4%

1.14.4 Outage *ecord and 8or Order.............................................................................................. 50

1.15 !/I & ec nica( !rc itecture -ie+........................................................................................... 51

1.15.1 Service Patterns...................................................................................................................... 51

1.15.2 Intra s"ste# vs. Inter s"ste#...................................................................................................521.15.3 Service !ggregation................................................................................................................ 53

1.15.4 /aster Data /anage#ent....................................................................................................... 54

1.15.5 )o#p(e' &vent Processing......................................................................................................54

1.15.6 overnance............................................................................................................................. 54

4. !ppendices.................................................................................................................56



12

1

2

3

45

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

2122

23

24

25

26

27

28

29

30

31

32

33

34

35

3

4


5/59


1.16 er#s and Definitions................................................................................................................... . 56

,ist of Fi uresigure 1. !/I &nterprise andscape diagra# s o+ing t e scope of t e service

definition effort...................................................................................................................igure 2. e Open roup !rc itecture ra#e+or : O ! ; s o+ing t e arc itecture

deve(op#ent c"c(e...........................................................................................................10

igure 3. !/I S"ste#s andscape.................................................................................11

igure 4. !c ieving tec nica( and se#antic interopera$i(it"< t e re(ations ip $et+een$usiness #ode(ing and design (a"er, $usiness process and inte((igence (a"er,integration (a"er, and app(ication (a"er............................................................................12

igure 5. !/I & S"ste#s *eference /ode(..............................................................22

igure 6. Integration *e uire#ents Deve(op#ent !pproac .........................................2

igure . S#art rid S"ste# of S"ste#s.......................................................................2%

igure %. &'a#p(e of services t at are provided or consu#ed $" custo#er infor#ation#anage#ent....................................................................................................................44

igure 9. )(ass re(ations ip diagra# representing t e #eter reading and re(atedevents..............................................................................................................................4

igure 10. )(ass re(ations ip diagra# s o+ing ref(ecting t e asset and custo#erinfor#ation.......................................................................................................................4%

igure 11. )(ass re(ations ip diagra# ref(ecting t e end device contro( re(ated o$=ects..........................................................................................................................................49

igure 12. )(ass re(ations ip diagra# s o+ing t e outage and +or order o$=ects......50



12

1

2

34

56

7

89

10

11

12

13

1415

1617

1819

2021

22

23

3

4


6/59


. Intro'uction#*+,-nterprise A#*+,-.TB is a utilit) led initiative under !tilit)#*+ and $pen %mart &rid A$pen%&Bwithin the !"# +nternational !sers &roup A!"#+ugB@ The #*+,-nterprise Tas( :orce defines s)stemsre uirements? policies? principles? est practices? and services re uired for information eCchange and

control etween #*+ related s)stems and utilit) enterprise front and ac( office s)stems@ #*+,-.T? asa utilit) led and vendor participant forum? is developing a set of utilit),ratified re uirements andspecifications for utilities to adopt and for vendors to implement@ The end,state of this effort willcontri ute to the development of open and interopera le #*+ solutions@ To that end? #*+,-.T willwor( ver) closel) with relevant %tandards ;evelopment $rgani ations A%;$sB such as +-" T"57 &14? *ulti%pea(? and others to ensure that #*+,-.T wor( products are compati le with their directionsand specifications and will e adopted as standards@

The #*+,-.T group is organi ed with four su ,groups Use Case Team to develop usiness process models and functional re uirements? which include

asic #*+ functionalit)? ;emand /esponse? Third part) data access etc@ SRS Team to develop overall s)stems architecture principles? integration re uirements and

specifications@ Service Definition Team to develop standards, ased? platform independent integration services

that support the usiness processes? adhere to the architecture principles and patterns? and areopen and interopera le when adopted ) vendor products@

Testing and Interoperability Team responsi le for the definition and development of test plans?unit? compliance? and interopera ilit) tests? ased on the services that have een defined as partof this standard@

The main goal of the tas( force is to wor( with utilities to develop re uirements and specificationsnecessar) to ena le vendors to deplo) open and standards, ased interopera le #*+ solutions@ This will

e achieved ) defining and ma(ing the following #*+,-.T related items availa le to the mar(et "ommon usiness processes "ommon architecture principles and patterns "ommon information model "ommon integration services Afunctional < informationalB "ompliance and interopera ilit) testing of and etween vendor products

. /urposeThe purpose of this document is to provide oth the functional and technical re uirements needed to serve

as the Drules of engagementE for how vendors and utilities could implement recommended re uirementsand design specifications in order to achieve interopera ilit)@ The focus of the #*+,-.T is integrationamong s)stems and'or applications to ena le #*+ usiness processes at the inter,s)stems level withinutilit) enterprise as well as etween utilit) and other entities A+%$'/T$s? other utilities? customersAresidential and "


7/59


." ScopeThe scope of #*+,-.T is the s)stems and'or applications within and around the utilit) enterprise and theinter,s)stems related usiness functions and stops at the oundaries of applications and the edge of utilit)enterprise@ The focus is on how these s)stems are to e integrated and composed to support #*+ related

usiness processes and functions@ -dge applications are those applications that communicate with

networ(s and devices in the field? as well as those that communicate with other usinesses or enterprisesAgenerall) defined as third partiesB@ -Camples of those applications are t)picall) #*+ ead,-nd s)stem?;emand /esponse "ontrol? ;istri ution management and operation A;*%'%"#;#B? -nerg)*anagement? ower Trading? etc@ The %/% will define a list of logical components and usinessfunctions and suggest a t)pical landscape of application components to support these #*+,-.T functionsto ensure applica ilit) and reusa ilit) of re uirements and services across different vendor product suitesand across different utilit) #*+ implementations@ +t includes scope? goals and o Fectives? architectural

principles? architecture considerations and patterns? #*+,-.T reference architectureG and specificre uirements@ The %/% will also reference #*+,-.T use cases? functional re uirements and servicedesign approach and artifacts@

The scope of #*+,-.T %/% document is to descri e what #*+,-.T is as an ecos)stem of integrated

applications? what collective functions it intends to provide? what s)stem architecture is re uired todeliver the intended functions? and what individual applications and the underlining technolog)infrastructure it re uires to support the esta lishment of #*+,-.T as such a s)stem@ This will lead toopen and interopera le components that can e delivered with different vendor products and'or solutionswithin the scope of #*+,-.T@

Figure 1. A I !nter"rise #ands$a"e diagram sho%ing the s$o"e of the servi$e definition effort.

Draft v1.0, Oct. 14, 2009 Page of 59


12

1

23456789

1011121314151617

181920212223

2425

26

3

4


8/59


#*+,-.T %/% intends to leverage availa le and applica le industr) est practices and standards for thiswor(? and to tie the re uired pieces together to support the stated goals of #*+,-.T as an ecos)stem of#*+ related processes? applications? and infrastructure technologies@ :rom the overall enterprisearchitecture standpoint? the %/% will leverage The $pen &roup #rchitecture :ramewor( AT$:B 9@0from The $pen &roup? which will serve as the framewor( for what needs to e defined and how the)relate to each other to support #*+,-.T s)stems re uirements@ :rom the integration architecturestandpoint? the %/% will leverage est practices and standards defined for %ervice,$riented #rchitectureA%$#B and its related technologies such as e %ervices and * %chema? as well as +-" 61968,1specification which defines standards for %)stems +nterfaces for ;istri ution *anagement for electricutilities@

#*+,-.T %/% does not include the following items that are t)picall) a part of solution architecture@%ome of them are or have een addressed ) other parts of the !tilit)#*+ initiative@ $thers will need to

e dealt with specificall) for each implementation@ %ecurit) architecture A#*+,%-"B .etwor( and hardware infrastructure architecture A#*+,.-TB

$perational architecture AT ;B Testing methodolog) and architecture AT ;B #pplication internal architecture Avendor product specificB

.0 Acronyms an' A11re&iationsThis su section provides a list of all acron)ms and a reviations re uired to properl) interpret the!tilit)#*+ #*+,-.T %)stem /e uirements %pecification@

#*+ #dvanced *etering +nfrastructure#*+,-.T #*+,-nterprise

%/% %)stem /e uirements %pecification%$# %ervice,$riented #rchitecture-% -nterprise %ervice us%;$ %tandards ;evelopment $rgani ation"+* +-" T"57 "ommon +nformation *odelT$: The $pen &roup #rchitecture :ramewor(!* !nified *odeling anguage;; ;ata ;efinition anguage

%; * %chema%; e %ervices ;efinition anguage

-%* -nterprise %emantic *odel-T -Ctra? Transform? oad-;+ -nterprise ;ata +ntegration*;* *eter ;ata *anagement*;!% *eter ;ata !nification %)stem Aa light weight *;*B-++ -nterprise +nformation +ntegration"- "ompleC -vent rocessing

+ usiness +ntelligence%,+ e %ervice H +nteropera ilit)

$#%+% $rgani ation for the #dvancement of %tructured

Draft v1.0, Oct. 14, 2009 Page % of 59


12

123456789

1011121314151617

181920

21

222324

3

4


9/59


+nformation %tandards

.2 E3ternal Consi'erations an' ReferencesThe wor( of #*+,-.T %/% is dependent upon the est practices availa le from the following entities

and standards organi ations

+-" T"57 or(ing &roup 14 A+-" 61968B series of standards? including the "ommon +nformation*odel

*ulti%pea( &rid ise #rchitecture "ouncil %ervice,$riented #rchitecture %tandards from 3"? %,+ and $#%+% The $pen &roup? T$: 9@0

.4 )ocument +&er&ie(

T$: 9@0 defines four architecture domains that are commonl) accepted as su sets of overall enterprisearchitecture? all of which T$: is designed to support? see :igure 1

Ar$hite$ture &ision defines overall architecture guiding principles? goals and o Fectives and desiredtraits@

The Business Ar$hite$ture defines the usiness strateg)? governance? organi ation? and (e) usiness processes@

The Data Ar$hite$ture descri es the structure of an organi ationIs logical and ph)sical data assetsand data management resources@ This is part of the Information Systems Ar$hite$ture @

The A""'i$ation Ar$hite$ture provides a lueprint for the individual application s)stems to edeplo)ed? their interactions? and their relationships to the core usiness processes of the organi ation@This is part of the Information Systems Ar$hite$ture @

The (e$hno'ogy Ar$hite$ture descri es the logical software and hardware capa ilities that arere uired to support the deplo)ment of usiness? data? and application services@ This includes +Tinfrastructure? middleware? networ(s? communications? processing? standards? etc@



12

1

2

3456789

101112

13

1415

1617

1819

2021

222324

252627

3

4


10/59


Figure ). (he *"en +rou" Ar$hite$ture Frame%ork ,(*+AF- sho%ing the ar$hite$ture deve'o"ment $y$'e.

#s such? the document will e structured as follows

Se$tion ) descri es the overall #rchitecture Jision for the s)stem? including &uiding rinciples?#rchitectural "onsiderations? and the #*+,-.T /eference *odel? all relevant to providing a consistentframewor( within which the four architecture components can e developed@

Se$tion provides the details of the four architecture components1@ Business Ar$hite$ture/ This will refer to wor( products produced ) the !se "ase and %ervice

;efinition Teams of #*+,-.T? which includes the list of use cases and integration re uirementsand usiness services at the functional level@

2@ Data Ar$hite$ture/ This provides the technical level re uirements relative to how the #*+,-.Tdata should e modeled and represented consistentl) across all integration services to ensuresemantic interopera ilit)@

3@ A""'i$ation Ar$hite$ture/ This provides the technical level re uirements relative to howapplications are modeled as logical components? and what services each logical components ma) provide or consume@ This should e an instantiation of the usiness services identified within the

usiness #rchitecture@4@ (e$hno'ogy Ar$hite$ture This provides the technical level re uirements relative to how

services will interact with each other to support end,to,end #*+ usiness processes@

Se$tion 0 contains the #ppendices? which includes terms and definitions? logical components list?integration re uirements list? and integration services view@



12

12

34

56789

10111213141516

171819202122232425

3

4


11/59


". Arc!itecture +&er&ie(

.5 Arc!itecture 6ision#s the ena ler of smart grid solutions? #*+ s)stems for utilities are still evolving as mar(et? regulator)

polic) and technolog) solutions evolve@ #s a whole? #*+ s)stems consist of the hardware? softwareand associated s)stem and data management applications that create a communications networ(

etween end s)stems at customer premises Aincluding meters? gatewa)s? and other e uipmentBand diverse usiness and operational s)stems of utilities and third parties , see Figure 2.

#*+,-.T is primarily concerned with the applications and technology infrastructure within theboundary of a utilitys enterprise, that are necessary to integrate and deliver the desiredbusiness processes. Figure 2 also shows representative components of AMI- !". For acomplete list of AMI- !" logical components, please go to the Appendi#.

Figure . A I Systems #ands$a"e

To achieve service,oriented integration design? technical interopera ilit) Ausing standards such as e%ervicesB and semantic interopera ilit) Ausing standards such as +-" "+*B must oth e addressed@ #s



AMIAMI--ENTENT

Enterprise 7us 8 Common Mo'el 9 Ser&ice

+uta e+uta eMana ementMana ement

Customer Customer Info. 9 7illinInfo. 9 7illin

Re&enueRe&enue/rotection/rotection

)istri1ution)istri1utionMana ementMana ement

AMI Ser&iceAMI Ser&iceMana er Mana er

*AN*ANMana ementMana ement

T!ir' /artyT!ir' /arty/ortal/ortal

Customer Customer /ortal/ortal

Meter Meter )ata)ata

Mana ementMana ement

)eman')eman'ResponseResponse


Meter AssetMeter AssetMana ementMana ement

AMI Net(orkAMI Net(orkAssetAsset


Representati&e of AMI-ENT components% not all inclusi&e.

12

1

2

34567

89

1011

12131415161718192021222324

2526272829303132333435363738394041

42

434445

3

4


12/59


such? a critical part of achieving desired architecture guiding principals Asee the neCt sectionB is tointroduce consistent semantics throughout the architecture? shown in :igure 3@

Figure 0. A$hieving te$hni$a' and semanti$ intero"erabi'ity the re'ationshi" bet%een business mode'ing anddesign 'ayer2 business "ro$ess and inte''igen$e 'ayer2 integration 'ayer2 and a""'i$ation 'ayer.

:igure 4 lists four maFor components of how to introduce consistent semantics into solution architecture@

Business ode'ing and Design #ayer T)picall)? usiness process modeling and design are done on a proFect ) proFect asis? governed? if availa le? ) a corporate +T lifec)cle process@ hat is missing ishow to introduce and manage consistent usiness semantics at design time@ The usiness *odeling and;esign a)er show that usiness process models will drive information service models? which aresupported ) an -nterprise %emantic *odel A-%*B@ The information service models are collections ofthe services? operations? and messages utili ed for information eCchange@ The -%* is developed througha com ination of industr) standards? internal application metadata? and usiness terms and definitionsGand is defined using !* constructs@ This model is transformed into %; and %; definitions fortransaction message eCchange or ;; for data ase information eCchange@ The output of the process andinformation service models will drive the run time environments in the three la)ers on the right@



12

12

3

4

56

7

8

910111213141516171819

3

4


13/59


#t the usiness process level? the recommended standard for integration etween the modeling and the process management applications is - @ rocess models could e generated in the form of - andcan e easil) transformed to eCecuta le processes@ This is critical to achieve usiness process levelinteropera ilit)@ #ccording to i(ipedia? - is an $rchestration language? not a choreograph)language A e %ervice "horeograph)B@ The primar) difference etween orchestration and choreograph)is eCecuta ilit) and control@ #n orchestration specifies an eCecuta le process that involves messageeCchanges with other s)stems? such that the message eCchange se uences are controlled ) theorchestration designer@ "horeograph) in this conteCt? specifies a protocol for peer,to,peer interactions?defining? e@g@? the legal se uences of messages eCchanged with the purpose of guaranteeinginteropera ilit)@ %uch a protocol is not directl) eCecuta le? as it allows man) different reali ationsAprocesses that compl) with itB@ # choreograph) can e reali ed ) writing an orchestration Ae@g@ in theform of a - processB for each peer involved in it@ The orchestration and the choreograph) distinctionsare ased on analogies orchestration refers to the central control A ) the conductorB of the ehavior of adistri uted s)stem Athe orchestra consisting of man) pla)ersB? while choreograph) refers to a distri uteds)stem Athe dancing teamB which operates according to rules ut without centrali ed control@

A""'i$ation #ayer ith the increasing amount of "ommercial,$ff,The,%helf A"$T%B applications eing implemented at utilities? the a ilit) to dictate how internal application data is modeled andrepresented is ver) limited@ !tilities can enforce consistent semantics on applications within an enterprisethat need to eCchange information and provide services outside of the application oundaries@#dditionall)? applications toda) are capa le of eing configured with fields that represent how a utilit)wants to see their data? thus enforcing consistent semantics at the &!+ and reporting levels@ +deall)?service end points at the application oundar) will adhere to the semantics of the -%*@ hen that is notthe case? the technologies such as -% or -++ A-nterprise +nformation +ntegrationB can e leveraged to

provide proC) services and transformation services to still eCposed -%* ased data to the enterprise oroutside of an enterprise@

Integration #ayer +n toda)Ks enterprise? several integration technologies coeCist@ :or eCample? the -%for process and services integration and -;+'-T '-++ for data integration co,eCist in an enterprise@ The

(e) to introducing consistent semantics is to have an -%* to drive oth the design of integration servicesAt)picall) in %; ' %; formatB and the design of the data services A-T ta lesB and data ase modelsA;; B@ This ensures that what is eCposed to the enterprise is a consistent representation of theinformation@ The -% provides a num er of important functions within an enterprise integrationinfrastructure? such as a straction AproC)B? managed integration? guaranteed deliver)? protocol mediation?etc@ The data integration technologies can e used to implement an -%* regardless of the ph)sicalstructure of the data on the ac(end s)stems@ ithin the conteCt of %mart &rid and #*+? one mustconsider the performance and securit) aspects of the utilit) operational needs versus the regular usiness

process integration and automation needs of ac('front office s)stems and design the integration la)eraccordingl)@ There is an increased desire to implement an operational -% that can e design to providesecure and scala le compleC event processing capa ilities in real time? as well as real time usinessintelligence driven data integration@

Business Pro$ess and Inte''igen$e #ayer #t the usiness process level the need to orchestrate multipleapplications to accomplish process automation or process management ma) eCist@ There is also the needto eCchange data with applications or users outside of the enterprise A 2 B? as well as to present usinessdata in a wa) that intelligence can e mined@ #ll of these issues spea( to the necessit) of a consistentrepresentation of usiness meaning AsemanticsB@ :or %mart &rid and #*+? 2 integration ta(es theform of utilit) s)stems integrated with s)stems from +%$'/T$? "


14/59


uilding energ) managementB? retailers? and other third part) service providers@ These integration pointsma) ver) well eCist within an end,to,end usiness process Afor eCample? a ;emand /esponse eventB@



12

12

3

3

4


15/59


.: Arc!itecture ;ui'in /rinciples#rchitecture guiding principles are rules of engagement designed to ensure that all aspects of theimplementation fit within a well,defined framewor(@ These principles? discussed and agreed upon with

all sta(eholders of the #*+,-.T? are used to drive the architectural approach and patterns to eimplemented@ These principles should not e ta(en lightl) as the) impl) what and how the overall goalsof #*+,-.T will e met@ -ach of the principles has a level of effort and cost implications for utilitiesand vendors loo(ing to adopt this specification@ #dherence to these principles can e adFusted for specificcases driven ) time and udget constraints@ These eCceptions should e approved ) all sta(e holdersand must e documented@

3 Name Des$ri"tion Rationa'e Im"'i$ation1 4ti'ity driven

and o"en"ro$ess

The process for developing?reviewing and ratif)ing the#*+,-.T specifications andartifacts including the %/%should e driven ) utilitiesand contri uted to ) vendors@+t shall e open to allmem ers of !"#+ug@

This is to ensure that theend product will reflectcollective views? desiresand goals of utilities and econsistent with thecapa ilities of thetechnologies and solutionson the mar(et? while eingvendor agnostic@

.eed to ensure a goodnum er of representativeutilities and solution

perspectives to participateand contri ute to theeffort@ !tilities need towor( together to developcommon usiness

processes to drive downcost and ris( of #*+ and%mart &rid@

) Business drivenar$hite$tureand design

/e uirements and architecture patterns and designs of thiseffort shall e driven ) realworld usiness re uirementsof #*+@

This will ensure thatrecommended solutionsdeliver real and specific

usiness re uirements and enefits@

This will re uire a topdown approach fordriving #*+,-.Tdelivera les? starting from

usiness processes andfunctional re uirementsAuse casesB

*"enintero"erabi'ity

The +--- definesinteropera ilit) as the a ilit)of two or more s)stems orcomponents to eCchangeinformation and to use theinformation that has eeneCchanged@

# complete interopera lesolution re uires s)stems orcomponents to interoperate at

oth the technical andsemantic levels@

%)stems that have greaterinteropera ilit) have lowerT"$ and lower ris(s ofimplementation@+nteropera ilit) ismanifested in ease ofoperation@ +t is not Fustinteropera ilit) within theorgani ation? ut acrossutilit) s)stems? whichre uires an open processand open access for the

mar(et place@

hen custom integrationis re uired for eachimplementation? it is notinteropera le@ $peninteropera ilit) impliesadopting relevantstandards where eCistenceand promote to standardsas de factoimplementations wherestandards gap eCist@#doption of an open

interopera le solutionre uires pu lic trust ofwide acceptance@

0 #everage and$o''aborate%ith industrystandards

here relevant industr)standards eCist to providereferences? est practices?eCisting wor( products? andfuture directions? the) should

e leveraged to reduce time

%tandards are the meansand vehicles for this effortto e successful@ This isalso a wa) to provideconcrete and organi edinput into the standards

%tart with standards thatare relevant@ :or eCample?+-" &14? *ulti%pea(?

3" A e %ervices?%chema? etc@B@"olla orate and contri ute



12

1

23

456789

10

3

4
http://en.wikipedia.org/wiki/IEEEhttp://en.wikipedia.org/wiki/IEEE


16/59


17/59


3 Name Des$ri"tion Rationa'e Im"'i$ation preclude future eCtensions ofthe architectureG e@g@ smartgrid@ +mplementation of #*+will also var) from utilit) toutilit)@

function ma) change@This group recogni es thatsmart grid represents a setof usiness functions andthat #*+ is a su set of that

capa ilit)@

wor( products shall eeasil) eCtended toenhance and maintainthem and their resultingimplementations@ #nd of

course? e eCtended intonew areas of usinessfunctionalit)@

.< Arc!itectural Consi'erations#*+,-.T as a s)stem needs to e architected with re uirements that cover the entire spectrum of

usiness? technical? and mar(et needs@ The following list of architecture attri utes will e used asguideline for #*+,-.T s)stems re uirements development@

%)stem ualit) attri utes discerna le at runtime

o erformance? %ecurit)? #vaila ilit)? :unctionalit)? !sa ilit)? %cala ilit)

%)stem ualit) attri utes .$T discerna le at runtime

o *odifia ilit)? orta ilit)? /eusa ilit)? +ntegrata ilit)? Testa ilit)

usiness Lualities

o Time to mar(etG "ostG roFected life time of the s)stemG Targeted mar(etG /olloutscheduleG -Ctensive use of legac) s)stem

Lualities directl) related to the architecture

o "onceptual integrit)G "orrectness and completenessG uilda ilit)

.$ Security Consi'erationsS$o"e

The details regarding design and implementation of various aspects of securit) are outside the scope ofthis document@ This information is within the scope of the #*+,%-" wor(ing group@ This document?however? descri es architectural assumptions and impacts of #*+,%-" re uirements specification to#*+,-.T s)stems re uirements@

Ar$hite$tura' Assum"tions

e assume that the s)stems descri ed in this document will e implemented over a wide variet) ofinfrastructures@ ;esigns ma) include oth wired and wireless communications as well as a miC of pu licand private networ(s@ The applications which run over this lend of underl)ing infrastructures must ecapa le of implementing ris(,appropriate securit) strategies in order to mitigate the impact of a range ofthreats@ %ecurit) for information eCchange etween applications will e supported ) oth the end points



12

1

2

34567

8

9

10

11

1213

14

15

16

17

18

19202122

2324

2526272829

3

4


18/59


that either consume or provide the information? as well as the middleware Aif an)B that provide thetransport and orchestration environment@

+n particular? the s)stem as a whole ma) e eCposed to several t)pes of threats

"ompromise of control Ai@e@? s)stem intrusionB *isuse of identit) or authorit) to gain inappropriate depth of access

-Cposure of confidential or sensitive information

;enial of service or access

reach of s)stem? import of errors Aintegrit)B

!nauthori ed use Aauthori ationB

!nidentified use'misuse AauthenticationB

*anipulation and destruction of records Aaudita ilit)'proofB

;ela)ed'misdirected'lost messages Arelia ilit)B

oss due to s)stem Aloss'damageB

ecause of the large num er of products and technologies which will e used in #*+ deplo)ments? thiss)stem assumes that la)ered securit) architecture will e designed and implemented@ %uch architectureallows for a lending of different cost,effective technologies with suita le ris( mitigation techni ues?including using compensating controls in the case that some s)stem components are not inherentl)secured@ %everal mechanisms ma) e emplo)ed across the la)ers of infrastructure? data management? andapplications to provide an appropriatel) secured s)stem@ #s an eCample? it ma) e possi le to userelativel) unprotected wireless infrastructure assuming that the applications which rel) on thatinfrastructure ta(e suita le steps to protect themselves from the t)pes of threats noted a ove@ +n the casethat infrastructure is etter hardened against threats? it is possi le that applications can e streamlinedwith a lighter weight securit) approach@

A""'ying A I;S!C S"e$ifi$ation to A I;!N(

:rom utilit) enterprise and #*+ enterprise level integration perspective? there are three predominanintegration environments to consider for securit) purpose

1@ !tilit) mission critical operational s)stems and data access'eCchange@

2@ !tilit) internal enterprise front and ac( office applications and data'eCchange@

3@ !tilit) eCternal application and data access'eCchange@

%ecurit) re uirements will need to e developed to support the specific needs of these environments@

#*+,%-" has pu lished a general set of securit) re uirements? which will need to e mapped onto the#*+,-.T re uirements for the purpose of securing the integration of applications@ ere is an initialanal)sis in terms of applica ilit) and impact of #*+,%%/ re uirements to #*+,-.T %/%@

Draft v1.0, Oct. 14, 2009 Page 1% of 59


12

12

34

56

7

8

9

10

11

12

13

14

15161718192021222324

2526

2728

2930

31

32

333435

3

4


19/59


A I;SSR Re-

#uthori ation is the approval of an actor to performan action@

$nl) authori edconsumerAsB of a servicecan invo(e the service

provider@

#uthori ation should esupported ) the integrationenvironment and'or the end

points that provide theservice@

Non;Re"udiation ,FNR- .on,/epudiation of .on,/epudiation ma) not e



12

1

3

4


20/59


A I;SSR Re


21/59


A I;SSR Re


22/59


. # AMI-ENT Reference Mo'el+n order for utilities to uild and vendors to deliver #*+ solution with interopera le components? areference model for #*+,-.T is needed@ This reference model will include all maFor components of

#*+,-.T and depict how the) relate to each other to function as a s)stem@ :igure 4 elow shows the#*+,-.T %)stems /eference *odel@

Figure 5. A I;!N( Systems Referen$e ode'

This reference model includes the following (e) categories of components1@ :unctional "omponents

#*+ -dge "omponents

#*+ "ustomer :acing "omponents

#*+ %pecific "omponents



AMI Customer Facin ComponentsAMI Customer Facin Components

AMI E' eAMI E' eComponentsComponents Utility +perations an' Enterprise Analysis ComponentsUtility +perations an' Enterprise Analysis Components

/rocess Inte ration /latform/rocess Inte ration /latform

Information Mana ement /latformInformation Mana ement /latform

Fe'erate'Fe'erate' ES7sES7s 8 ESM8 ESM

EII=E)I=ET, 8 ESMEII=E)I=ET, 8 ESM

Meta'ataRepository

Ser&iceMana ement

SecurityMana ement

/rocess+rc!estration

Monitorin 9Mana ement

)ata >are!ouse9 )ata Mart

Reportin9 Analysis

AMI SpecificComponents

AMI*ea' En' ?n

)eman'Response

Comman' 9 Control

AMISer&iceMana er

AMI*ea' En' ?"

AMI*ea' En' ?-

AMI MeterAsset

Maintenance

Utility +perations an' EnterpriseUtility +perations an' EnterpriseComponentsComponents

AMI Net(orkAsset

Maintenance

C9I )eman'Resource

Mana ement

AMINet(ork

Mana ement

Customer Information

Analysis

CustomerInformation

Mana ement

Customer /resentment 9

Analysis@C9I

Customer /resentment 9

Analysis@Resi'ential

CustomerRelations!ipMana ement

)istri1utionEn ineerin

Analysis

)istri1utionMana ement

)istri1ution+perational

Analysis

)eman'Response

Mana ement

)istri1utionSCA)A

Enterprise AssetMana ement

Ener yMana ement

;eo rap!icInformation

Mana ement

*ome AreaNet(ork

Mana ement

Meter )ataMana ement

>ork an' Mo1ileMana ement

+uta eMana ement /o(er Tra'in

Re&enue/rotection

Supply C!ainMana ement

Transformer ,oa' Mana ement

T!ir' /arty/ortal

Meter )ataAnalysis

Customer /ortal

Comple3E&ent /rocessin

Real Time7I

12

1

23

45

67

8

910

11

12

1314

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

3031

32

33

34

3

4


23/59


!tilit) $perations and -nterprise #nal)sis "omponents

!tilit) $perations and -nterprise "omponents

2@ Technical "omponents

rocess +ntegration latform

+nformation *anagement latform

The intent of this reference model is to include all potential logical components of the #*+,-.T? giventhe current understanding of the usiness needs of #*+ for %mart &rid@ #s the %mart &rid vision andcapa ilities continue to mature and as #*+ technologies and applications continue to evolve? thisreference model will evolve as well@ The technical components of the reference model is ased upon thecurrent understanding the est practices for enterprise +T? including the use of %ervice,$riented#rchitecture for integration and informalit) management? and the use of real time data management and

usiness intelligence technologies to support the future operational needs of %mart &rid@

-ach utilit) #*+ implementation will need to map its usiness re uirements? application portfolio andeCisting technolog) infrastructure to this #*+,-.T reference architecture@ here gaps eCist? eachimplementation will evaluate alternative solution for supporting this architecture@

The following ta le descri es each component of the #*+,-.T reference architecture@ +n each of thefollowing architecture views? details of these components will e further specified@

Category Name Note(e$hni$a'P'atforms

Federated !SB !S 1@ -% refers to a middleware platform that could ena leapplication and process integration through services to ensuretechnical interopera ilit)@ -% is not re uired ut desira lefor man) reasons@

2@ -% also offers the t)pical middleware features such asservice a stractionG guaranteed deliver)? routing?transformation where necessar)? protocol mediation?monitoring < eCception handling and asic orchestration@

e %ervices is the preferred technolog) for services designand implementation? although other techni ues should also econsidered for performance and'or volume'si e reasons@

3@ ;ue to different performance and securit) re uirements etween utilit) operations and usiness managementfunctions? a federated -% environment ma) e re uired tosupport the future %mart &rid re uirements@

4@ -%* refers to an information model that is used to drive all pa)load definition Acanonical modelsB of services to ensure

semantic consistenc) and interopera ilit)@ -%* is re uired toderive consistent semantics in the canonical models@ -%* for#*+,-.T must e semanticall) consistent with the industr)standard models such as "+*? *ulti%pea(? etc@ to ensure openinteropera ilit)@

Pro$ess *r$hestration rocess orchestration ma) e needed for long running transactions? processes? and for compleC and'or composite servicesmanagement@

Com"'e: !ventPro$essing

"ompleC event processing will e re uired to support #*+ and%mart &rid needs as grid operations will leverage #*+



12

1

2

3

4

5

6

789

10111213

141516

1718

19

3

4


24/59


Category Name Noteinfrastructure to drive more real time decision ma(ing andoperational activities@

onitoring anagement

asic *onitoring and management of services for eCceptionhandling and issue resolution@#dvanced usiness #ctivit) *onitoring A #*B capa ilities ma)

e used to collect and anal) e #*+ related usiness process performance metrics@!II@!DI@!(# !S 1@ -++'-;+ refers to -nterprise +nformation *anagement and

-nterprise ;ata +ntegration@ -T refers to the traditional dataintegration tool A-Ctract? Transform and oadingB for datawarehouse@

2@ -%* in this case refers to use the same information model asused in the process integration to drive the metadata and datawarehouse model design and to drive -T transformationdesign@

3@ There will e needs for oth process integration and dataintegration? and oth of them will e increasingl) more realtine@

Data arehouse and Dataart This can e oth operational data mar(et for specific domain andutilit) enterprise data warehouses@Rea' (ime BI This component will ecome more critical as the re uirements of

#*+ and %mart &rid will drive more real time + and reporting@The oundar) etween process integration and data managementwill lur even more as usiness operations demand more real timedata and anal)sis@

Re"orting and Ana'ysis usiness intelligence and reporting for data and information acrossmultiple applications and processes to support traditional usinessanal)sis and decision ma(ing needs@

etadata Re"ository This is to capture usiness and technical metadata for integrationand +'; @ *ost utilities do not have this in place? ut increasinginformation management needs will put this technolog) intoforefront of ena ling +T infrastructure@

Servi$es anagement %ervice registr)? repositor) and version management@;)namic discover) is not an initial re uirement ut ma) provide

enefits for overall service lifec)cle management@Se$urity anagement +dentif) management

%ecurit) ena lementThe use of * #ppliance technolog) for performance andsecurit) implementation@

A I !dgeCom"onents

A I ?ead !nd 31 There could e multiple #*+ .etwor( and *etering technologiesfor a given utilit) enterprise@A I ?ead !nd 3)

A I ?ead !nd 3nA I !vent Servi$e

anager

#*+ event management for multiple #*+ ead -nds for all event

handling and management@*a) e provided ) a *;*% vendor or leverage -%infrastructure and %$# design or a custom developed componentfor specific #*+ technologies@

Demand Res"onseCommand Contro'

rovides ;/ related messaging and command and control? ma) gothrough #*+ networ( or use its own networ(@%imple one wa) paging or two wa) communication@

A I Net%orkanagement

*anaging #*+ networ( operations? as part of the utilit)communications group? or other means@*a) e leveraging other communication provider infrastructure@



12

3

4


25/59


Category Name Note

A ICustomerFa$ingCom"onents

Customer Porta' # general purpose customer information we site@ ith increasinginformation a out ;/ programs? etc@

(hird Party Porta' # we site for third parties to access #*+ related data@C I Customer

Presentment Ana'ysis

rovides "


26/59


Category Name NoteSu""'y Chain

anagement#*+ networ( and meter installation support

(ransformer #oadanagement

*ore accurate load profile data for transformer asset management



12

1

3

4


27/59


0. AMI-ENT Systems Arc!itecture

. AMI-ENT 7usiness Arc!itecture 6ie(

1.11.1 Integration Requirements Framework +ntegration re uirements development is critical to ensure that the implemented solution delivers theintended usiness functions and enefits@ :igure 5 shows the approach to identif) the integrationre uirements and develop the associated services@ These services will e implemented to support the

usiness processes that ultimatel) ena le the usiness enefits intended ) an #*+ program@ The usecases and scenarios captured as part of the #*+,-.T !se "ase team is reall) a representation of usiness

processes and su ,processes? so the) are considered e uivalent in the conteCt of the re uirementsdevelopment@

Figure 6. Integration Re


28/59


Ainformation or functional flowB etween two activities Aespeciall) if the) come from differents)stems or functional areasB would result in an integration re uirement@

Business "ro$ess to IR / the current scenario Asu ,processB uses a defined set of s)stems from%/% as swim lanesG this would e mapped to an +nterface /eference *odel A+/*B for separationof function and s)stem@ The +/* for #*+,-.T is the ogical "omponents *odel? see#ppendiC@

IR to A""'i$ation Portfo'io/ the candidate or legac) applications that support a particular +/*component will e mapped to show the ena lement of a specific component of the +/*@

Integration re


29/59


#*+,-.T covers oth the intra,s)stem interfaces within a utilit) enterprise and the inter,s)steminterfaces etween utilit) and other organi ations shown in the diagram@ The following ta le lists theorgani ational actors that will participant the #*+ and %mart &rid usiness processes@

*rgani=ationa' A$tor Name A$tor Des$ri"tion

IS*@R(* +ndependent %)stem $perator ' /egionalTransmission $perator

Residentia' Customer ess than 20(wh consumption for a )ear

Sma'' to edium C ICustomer

# out 20,200 (wh consumption for a )ear

#arge C I Customer *ore than 200(wh consumption for a )ear

Demand Res"onse Aggregator # usiness that aggregates ;/ capacit) on ehalf of a group of energ) consumers@

+enerator ower generation

4ti'ity E !nergy Net%ork*"eration !tilit) energ) deliver) networ( andmanagement organi ation

4ti'ity E Communi$ationNet%ork *"eration

!tilit) communications networ( andmanagement organi ation

4ti'ity E Customer Servi$e !tilit) customer services organi ation

4ti'ity E !ngineering !tilit) engineering and design organi ation

4ti'ity E Fie'd *"eration !tilit) field service and constructionorgani ation

(hird Party Servi$e Provider usiness that provides value added services ontop of the asic energ) services that utilit)

provides@

. ."." ,o ical Components ,ist

ogical "omponents are one wa) to organi e interfaces Aintegration servicesB for #*+,-.T@ :ollowingis a ta le listing all maFor logical components that will provide some functions to support #*+ usiness

processes@ This logical component list serves as the +/* for #*+,-.T@ #ll services will e organi edaccordingl)@

3 A$ronym #ogi$a'Com"onents

Des$ri"tion @ ey Business Fun$tions Notes a" to I!C61968;9

1 A I ?! A I ?ead;!nd

# s)stem that acts as a gatewa) tocommunicate etween utilit) enterprises)stems and field devices Amostl) #*+metersB through #*+ networ(@ #llowtwo wa) communications etweenenterprise s)stems and #*+ networ(and devices@

-ach ead,-nd t)picall)wor(s with a vendor specific#*+ networ( technolog)

eteringSystem



12

1

234

5

67

89

1011

12

3

4


30/59




) A IA

A I eterAsset

aintenan$e

# s)stem that helps the #*+ metertesting? trac(ing and maintenanceactivit) planning@

#n -#* ma) not e specificenough to support all #*+meter related testing andtrac(ing needs@

eteringaintenan$e

A I NA A I Net%ork

Assetaintenan$e

# s)stem that manages the maintenance

of the #*+ networ( assets@

*a) e part of a utilit)

enterprise asset managements)stem or part of the utilit)telecommunication networ(assets maintenance s)stem

0 A I N A I Net%orkanagement

# s)stem that manages the operations ofthe #*+ networ( and devices@

*a) or ma) not e part ofthe #*+ ead,-nd

5 A I S A I !ventServi$e

anager

This is a s)stem that sits on top of the#*+ -% and provides a wa) forsomeone who wants to poll a specificmeter to e a le to do so transparentl)@# s)stem that acts as a gatewa) tocommunicate etween utilit) enterprises)stems and field devices Amostl) #*+metersB through #*+ networ(@

# ilit) for "ustomer %ervice/epresentatives and other usiness personnel to uer) specific devices toresolve issues in a short period of time@/outing of alert and alarms in near realtime

This assumes that there aremultiple head ends H eitherfrom a single vendor Ascaleof implementationB ormultiple #*+ vendors onsite@ *ost #*+ -% are notdesigned to pass near realtime information and are

t)picall) polled@

6 C I DR C ICustomerDemandResour$e

anagement

*anages the information that is provided ) "


31/59




1) D!A Distribution!ngineeringAna'ysis

# data ase that provides networ(?e uipment'asset? load profile? and otherengineering related data for engineeringanal)sis and reporting needs@

#oadanagement

System

1 D S Distributionanagement

# s)stem that manages the distri utionnetwor( operations@

*a) include advancedistri ution automationfeatures of a t)pical %mart&rid capa ilities@

Net%ork*"erations,61968; -

10 D*A Distribution*"erationa'Ana'ysis

# data ase that provides distri utionoperational histor) and near real timedata for operational anal)sis andreporting@


15 DR DemandRes"onse

anagement

# s)stem that manages the demandresponse programs from utilit) point ofview@ +ncludes load control? integrationwith ;*%? and ;/ programmanagement@ !ses historical andeCternall) input data to ma(e

predictions and what,if anal)sis for ;/ purposes

#oadanagement

System

16 DSCADA DistributionSCADA

# %"#;# s)stem for the purpose ofdistri ution operation@


17 !A !nter"riseAsset

anagement

# s)stem that manages the utilit)enterprise assets including networ(e uipments and others@

*a) e sufficient forsu station e uipment assetmanagement and /elia ilit)"entered *aintenanceA/"*B

eter Assetanagement

18 ! !nergyanagement

# s)stem that manages the transmissionnetwor( operations

)G +I +eogra"hi$Information

anagement

# s)stem that provide spatialmanagement capa ilities for utilit)facilities and assets@

*a) include a &+% asedgraphical design tool@

)1 ?AN ?ANanagement

# s)stem that allows utilities to sendmessages Asuch as pricing? illing? usageor alarmsB to customer displa) devicesA+ ;sB@ *anages the enrollment ofdevices in specific home area networ(s?management the enrollment of thosedevices in programs? manages the de,enrollment in programs and from the

#.

This is similar to an assetmanagement s)stem? utta(es on the role offacilitating which #.;evices are registered withthe utilit) or a third part) andcan receive signals@ The

#.* ma) (now thecommand protocol for eacht)pe of #. ;evice and therelationship of the #.device to a load at thecustomer site@ #.* ma)also serve small usinessesas well as residentialcustomers

)) D eter Dataanagement

# s)stem that manages all #*+ meterreads and provides necessar)validations?

"ould also act as a gatewa)for #*+ - s)stems tocommunicate to other utilit)enterprise s)stems@

eter Dataanagement



12

3

4


32/59




) D( obi'e Data(ermina'

# mo ile data platform withapplications to support field technicianneeds? which often include maps?facilit) data? service orders? customerinformation? meter information? etc@

*a) e separate applicationin one or more mo ile

platforms@

orkanagement

)0 F obi'eorkfor$eanagement

# s)stem that manages mo ilewor(force? which t)picall) focuses onservice Ashort durationB and emergenc)wor( orders@

+ntegrates with a mo ile platform

orkanagement

)5 * *utageanagement

# s)stem that helps locates and restoresoutages@

*utageanagement

)6 P ,IS*- Po%er arketanagement

,IS*-

# s)stem that helps +%$ manages powertrading and clearing in forward and realtime mar(ets@

)7 P( , P- Po%er(rading , P-

# s)stem that ena les a *ar(etarticipant A* B to trade power with

others through +%$ power mar(et@

-na les a mar(et participant to id loadApotentiall) aggregatedB to the +%$ fordemand response

)8 RP RevenueProte$tion

# s)stem to help identif) potentialenerg) theft activities? and generateenerg) theft related service orders@

/evenue protection anal)sisusing #*+ meter data andother related data Acustomer

profile? weather?consumption pattern? etc@B

)9 SP Su""'y Chainanagement

# s)stem to manage materials ande uipment purchasing? inventor) andvendors@

G (# (ransformer#oad

anagement

# s)stem that gathers load profile dataat the transformer level@

oad data from #*+ meterswill e more granular andaccurate@

#oadanagement

System1 (PP ,A I- (hird Party

Porta' ,A I-# s)stem that allows third parties Anoncustomer entitiesB to re uest actions andhave access to #*+ related data for theirmeters? etc@

This would appl) to utilit)#*+ deplo)ment for non,utilit) own meters ordevices@

) orkanagement

# s)stem that helps manage utilit)capital proFects and new usiness relatedwor(@

orkanagement

S orkS$hedu'ing

# s)stem that helps manage andschedule long duration? short durationand emergenc) t)pes of wor( for autilit) enterprise@

*a) e managed ) separates)stems if an enterprise widescheduling s)stem is notavaila le@

+as re'ated

$om"onentsH



12

1

2

3

4


33/59


. " Inte ration Requirements Specification

1.12.1 Functional Requirements Business !rocessesThe usiness processes that have een developed as part of #*+,-.T are listed as follows@ .ote thatlin( to the www@%mart&ridi edia@org for details of each usiness process Ause caseB@

1 , *eter /eading

o 1 , %cenario 1 , #*+ *eter completes scheduled read re uest

o 1 , %cenario 2 , #*+ *eter completes an on,demand read

o 1 , %cenario 3 , #*+ *eter transmits non,usage AeventB messages

o 1 , %cenario 5 , ;ata users successfull) retrieve either raw or ill read) usage data

o 1 , %cenario 6 , #*+ ead -nd manages the meter reading schedule

o 1 , %cenario 7 , Third part) accesses #*+ data

o 1 , %cenario 8 , Third art) uses !tilit)Is #*+ .etwor( to read their meters

o 1 , %cenario 9 , *eter does not communicate remotel) during default schedule read

o 1 , %cenario 12 , :ield %ervice /ep retreves data directl) from the #*+ *eter

o 1 , %cenario 15 , The *eter ;ata !nification %)stem issues communications service order forfailure to retrieve illing data

o 1 , %cenario 16 , *eter does not respond to an on,demand read

o 1 , %cenario 17 , *eter /ead /e uest

2 , /emote "onnect';isconnect

o 2 , %cenario 1 , "ustomer re uests routine electric service turn off A*ove outB

o 2 , %cenario 2 , "ustomer re uests routine electric service turn on A*ove inB

o 2 , %cenario 3 , !tilit) disconnects customer for credit or collection cause

o 2 , %cenario 4 , !tilit) reconects customer following credit and collection disconnect

o 2 , %cenario 5 , :ield erson performs local electric service connection or disconnection

o 2 , %cenario 6 , !tilit) limits customerIs electric service due to credit or collection causes

3 , ;etect Theft

o 3 , %cenario 1 , *eter removal



12

1

234

5

6

7

8

9

10

11

12

13

14

1516

17

18

19

20

21

22

23

24

25

26

27

3

4
http://www.smartgridipedia.org/http://www.smartgridipedia.org/http://www.smartgridipedia.org/http://www.smartgridipedia.org/index.php/B1_-_Meter_Readinghttp://www.smartgridipedia.org/index.php/B1_-_Scenario_1http://www.smartgridipedia.org/index.php/B1_-_Scenario_2http://www.smartgridipedia.org/index.php/B1_-_Scenario_3http://www.smartgridipedia.org/index.php/B1_-_Scenario_5http://www.smartgridipedia.org/index.php/B1_-_Scenario_6http://www.smartgridipedia.org/index.php/B1_-_Scenario_7http://www.smartgridipedia.org/index.php/B1_-_Scenario_8http://www.smartgridipedia.org/index.php/B1_-_Scenario_9http://www.smartgridipedia.org/index.php/B1_-_Scenario_12http://www.smartgridipedia.org/index.php/B1_-_Scenario_15http://www.smartgridipedia.org/index.php/B1_-_Scenario_15http://www.smartgridipedia.org/index.php/B1_-_Scenario_15http://www.smartgridipedia.org/index.php/B1_-_Scenario_16http://www.smartgridipedia.org/index.php/B1_-_Scenario_17http://www.smartgridipedia.org/index.php/B2_-_Remote_Connect/Disconnecthttp://www.smartgridipedia.org/index.php/B2_-_Scenario_1http://www.smartgridipedia.org/index.php/B2_-_Scenario_2http://www.smartgridipedia.org/index.php/B2_-_Scenario_3http://www.smartgridipedia.org/index.php/B2_-_Scenario_4http://www.smartgridipedia.org/index.php/B2_-_Scenario_5http://www.smartgridipedia.org/index.php/B2_-_Scenario_6http://www.smartgridipedia.org/index.php/B3_-_Detect_Thefthttp://www.smartgridipedia.org/index.php/B3_-_Scenario_1http://www.smartgridipedia.org/http://www.smartgridipedia.org/index.php/B1_-_Meter_Readinghttp://www.smartgridipedia.org/index.php/B1_-_Scenario_1http://www.smartgridipedia.org/index.php/B1_-_Scenario_2http://www.smartgridipedia.org/index.php/B1_-_Scenario_3http://www.smartgridipedia.org/index.php/B1_-_Scenario_5http://www.smartgridipedia.org/index.php/B1_-_Scenario_6http://www.smartgridipedia.org/index.php/B1_-_Scenario_7http://www.smartgridipedia.org/index.php/B1_-_Scenario_8http://www.smartgridipedia.org/index.php/B1_-_Scenario_9http://www.smartgridipedia.org/index.php/B1_-_Scenario_12http://www.smartgridipedia.org/index.php/B1_-_Scenario_15http://www.smartgridipedia.org/index.php/B1_-_Scenario_15http://www.smartgridipedia.org/index.php/B1_-_Scenario_16http://www.smartgridipedia.org/index.php/B1_-_Scenario_17http://www.smartgridipedia.org/index.php/B2_-_Remote_Connect/Disconnecthttp://www.smartgridipedia.org/index.php/B2_-_Scenario_1http://www.smartgridipedia.org/index.php/B2_-_Scenario_2http://www.smartgridipedia.org/index.php/B2_-_Scenario_3http://www.smartgridipedia.org/index.php/B2_-_Scenario_4http://www.smartgridipedia.org/index.php/B2_-_Scenario_5http://www.smartgridipedia.org/index.php/B2_-_Scenario_6http://www.smartgridipedia.org/index.php/B3_-_Detect_Thefthttp://www.smartgridipedia.org/index.php/B3_-_Scenario_1


34/59


o 3 , %cenario 3 , *eter is inverted

o 3 , %cenario 4 , *eter )pass detection at the *eter

o 3 , %cenario 5 , h)sical tamper detection

o 3 , %cenario 6 , !nauthori ed meter location change 4 , "ontract *eter /eading

o 4 , %cenario 1 , -lectric utilit) performs regularl) scheduled gas'water meter read

o 4 , %cenario 5 , -lectric utilit) performs event detection monitoring of gas'water *eter

o 4 , %cenario 6 , -lectric utilit) performs event monitoring of gas'water *eter

"onsolidated ;emand /esponse and oad "ontrol

o ;/ and oad "ontrol

"1 , rice ased ;/ and Joluntar) oad "ontrol

o "1 , %cenario 2 , The #*+ *eter does not respond to a voluntar) demand response eventnotification

"2 , "ustomer Jiews -nerg) ;ata

o "2 , %cenario 1 , The "ustomer views their energ) and cost data on the #*+ *eter or displa)device at their site

o "2 , %cenario 2 , The "ustomerIs #. ;ispla) ;evice is provisioned to accept information fromthe #*+ %)stem

o "2 , %cenario 3 , The "ustomer views energ) data for their site ) internet

o "2 , %cenario 5 , The "ustomer receives messages on the #*+ *eter or #. ;ispla) ;evice

"3 , repa)ment

o "3 , %cenario 1 , "ustomer prepa)s for electric service

o "3 , %cenario 2 , "+% %ends prepa)ment rate updates

o "3 , %cenario 3 , "+% cancels prepa)ment electric service

o "3 , %cenario 4 , #*+ *eter -nters "redit' oad imit mode

"4 , Third arties !se #*+ .etwor(

o "4 , %cenario 1 , Third art) compan) monitors "ustomer e uipment on,demand

;2 , ;istri ution #utomation

o ;2 , %cenario 1 , ;istri ution -ngineering optimi es networ( ased on voltage /*% variationinformation at the customer site



12

1

2

3

45

6

7

8

9

10

11

1213

14

1516

1718

1920

21

22

23

24

25

26

27

28

2930

3

4
http://www.smartgridipedia.org/index.php/B3_-_Scenario_3http://www.smartgridipedia.org/index.php/B3_-_Scenario_4http://www.smartgridipedia.org/index.php/B3_-_Scenario_5http://www.smartgridipedia.org/index.php/B3_-_Scenario_6http://www.smartgridipedia.org/index.php/B4_-_Contract_Meter_Readinghttp://www.smartgridipedia.org/index.php/B4_-_Scenario_1http://www.smartgridipedia.org/index.php/B4_-_Scenario_5http://www.smartgridipedia.org/index.php/B4_-_Scenario_6http://www.smartgridipedia.org/index.php/Consolidated_Demand_Response_and_Load_Controlhttp://www.smartgridipedia.org/index.php/DR_and_Load_Controlhttp://www.smartgridipedia.org/index.php/C1_-_Price_Based_DR_and_Voluntary_Load_Controlhttp://www.smartgridipedia.org/index.php/C1_-_Scenario_2http://www.smartgridipedia.org/index.php/C1_-_Scenario_2http://www.smartgridipedia.org/index.php/C2_-_Customer_Views_Energy_Datahttp://www.smartgridipedia.org/index.php/C2_-_Scenario_1http://www.smartgridipedia.org/index.php/C2_-_Scenario_1http://www.smartgridipedia.org/index.php/C2_-_Scenario_2http://www.smartgridipedia.org/index.php/C2_-_Scenario_2http://www.smartgridipedia.org/index.php/C2_-_Scenario_3http://www.smartgridipedia.org/index.php/C2_-_Scenario_5http://www.smartgridipedia.org/index.php/C3_-_Prepaymenthttp://www.smartgridipedia.org/index.php/C3_-_Scenario_1http://www.smartgridipedia.org/index.php/C3_-_Scenario_2http://www.smartgridipedia.org/index.php/C3_-_Scenario_3http://www.smartgridipedia.org/index.php/C3_-_Scenario_4http://www.smartgridipedia.org/index.php?title=C4_-_Third_Parties_Use_AMI_Network&action=edit&redlink=1http://www.smartgridipedia.org/index.php/C4_-_Scenario_1http://www.smartgridipedia.org/index.php?title=D2_-_Distribution_Automation&action=edit&redlink=1http://www.smartgridipedia.org/index.php/D2_-_Scenario_1http://www.smartgridipedia.org/index.php/D2_-_Scenario_1http://www.smartgridipedia.org/index.php/B3_-_Scenario_3http://www.smartgridipedia.org/index.php/B3_-_Scenario_4http://www.smartgridipedia.org/index.php/B3_-_Scenario_5http://www.smartgridipedia.org/index.php/B3_-_Scenario_6http://www.smartgridipedia.org/index.php/B4_-_Contract_Meter_Readinghttp://www.smartgridipedia.org/index.php/B4_-_Scenario_1http://www.smartgridipedia.org/index.php/B4_-_Scenario_5http://www.smartgridipedia.org/index.php/B4_-_Scenario_6http://www.smartgridipedia.org/index.php/Consolidated_Demand_Response_and_Load_Controlhttp://www.smartgridipedia.org/index.php/DR_and_Load_Controlhttp://www.smartgridipedia.org/index.php/C1_-_Price_Based_DR_and_Voluntary_Load_Controlhttp://www.smartgridipedia.org/index.php/C1_-_Scenario_2http://www.smartgridipedia.org/index.php/C1_-_Scenario_2http://www.smartgridipedia.org/index.php/C2_-_Customer_Views_Energy_Datahttp://www.smartgridipedia.org/index.php/C2_-_Scenario_1http://www.smartgridipedia.org/index.php/C2_-_Scenario_1http://www.smartgridipedia.org/index.php/C2_-_Scenario_2http://www.smartgridipedia.org/index.php/C2_-_Scenario_2http://www.smartgridipedia.org/index.php/C2_-_Scenario_3http://www.smartgridipedia.org/index.php/C2_-_Scenario_5http://www.smartgridipedia.org/index.php/C3_-_Prepaymenthttp://www.smartgridipedia.org/index.php/C3_-_Scenario_1http://www.smartgridipedia.org/index.php/C3_-_Scenario_2http://www.smartgridipedia.org/index.php/C3_-_Scenario_3http://www.smartgridipedia.org/index.php/C3_-_Scenario_4http://www.smartgridipedia.org/index.php?title=C4_-_Third_Parties_Use_AMI_Network&action=edit&redlink=1http://www.smartgridipedia.org/index.php/C4_-_Scenario_1http://www.smartgridipedia.org/index.php?title=D2_-_Distribution_Automation&action=edit&redlink=1http://www.smartgridipedia.org/index.php/D2_-_Scenario_1http://www.smartgridipedia.org/index.php/D2_-_Scenario_1


35/59


36/59


o +3 , %cenario 1 , !tilit) !pgrades #*+ to #ddress :uture /e uirements

o +3 , %cenario 2 , #*+ registers customer owned devices for communication on the #.

o +3 , %cenario 3 , !tilit) upgrades #. technolog)

o +3 , %cenario 4 , !tilit) upgrades .#. technolog)

o +3 , %cenario 5 , !tilit) upgrades #. technolog)

%1 , #*+ %)stem /ecover)

o %1 , %cenario 1 , #*+ ead -nd detects individual meter communiations failure

o %1 , %cenario 2 , *eter responds to communications failure

o %1 , %cenario 3 , #*+ ead -nd detects *eter failures in an area

he demand response management related use cases are eing developed and will e posted to the

same we site as the) ecome availa le@ ere is an initial list of ;/ related usiness processes underdevelopment@ #s the ;/ use cases are full) developed? the integration re uirements and services will e developed thereafter@

*anage ;/ program

rovision ;emand /esponse - uipment

*anage ;emand for -conomic ;ispatch

*anage ;emand for &rid /elia ilit)

*anage -nerg) rocurement

*anage :ield %ervices < %)stem /ecover)

erform +nstallation and *aintenance

rovide "ustomer %ervice and illing

;a) #head lanning



12

1

2

3

4

5

6

7

8

9

1011

1213141516

17

18

19

20

21

22

23

24

25

26

27

28

29

30

3

4
http://www.smartgridipedia.org/index.php/I3_-_Scenario_1http://www.smartgridipedia.org/index.php/I3_-_Scenario_2http://www.smartgridipedia.org/index.php/I3_-_Scenario_3http://www.smartgridipedia.org/index.php/I3_-_Scenario_4http://www.smartgridipedia.org/index.php/I3_-_Scenario_5http://www.smartgridipedia.org/index.php?title=S1_-_AMI_System_Recovery&action=edit&redlink=1http://www.smartgridipedia.org/index.php/S1_-_Scenario_1http://www.smartgridipedia.org/index.php/S1_-_Scenario_2http://www.smartgridipedia.org/index.php/S1_-_Scenario_3http://www.smartgridipedia.org/index.php/I3_-_Scenario_1http://www.smartgridipedia.org/index.php/I3_-_Scenario_2http://www.smartgridipedia.org/index.php/I3_-_Scenario_3http://www.smartgridipedia.org/index.php/I3_-_Scenario_4http://www.smartgridipedia.org/index.php/I3_-_Scenario_5http://www.smartgridipedia.org/index.php?title=S1_-_AMI_System_Recovery&action=edit&redlink=1http://www.smartgridipedia.org/index.php/S1_-_Scenario_1http://www.smartgridipedia.org/index.php/S1_-_Scenario_2http://www.smartgridipedia.org/index.php/S1_-_Scenario_3


37/59


1.12.2 Functional Requirements Integration "er#ices!sing a consistent methodolog) to identif) integration re uirements from the use cases list a ove? the%ervices ;efinitions Team identified the following re uirements and applies services naming patterns? see

Technical #rchitecture section? to derive the following list services and its providers@ :or more detailsa out these integration re uirements and services? please go to www@%mart&ridi edia@org@ lease notethe each re uirement has a use case scenario num er? such as 1,%1? to tie it ac( to the usiness process@

4se CaseS$enario

IntegrationRe


38/59


39/59


4se CaseS$enario

IntegrationRe


40/59


4se CaseS$enario

IntegrationRe


41/59


4se CaseS$enario

IntegrationRe


42/59


1.12.$ %echnical Requirements Integration "er#ices

+ntegration services that are well defined? understood and managed are the linchpin of an open and

interopera le #*+ implementation oth within a utilit) enterprise and etween the utilit) enterprise andother usiness entities@ :ollowing is a list of guiding principles for integration services design

N "ommon protocol and usiness semantics should e used to achieve loosel) coupling of end, point service Adirectl) or indirectl)B

N %ervices should e representative of a uni ue unit of wor( and reusa le across usiness functions@

N %ervices should e reusa le across common practices of utilities@

N %ervice design should e driven ) usiness re uirements and reflected in the architecture@

N %ervice design should e governed with a common approach and framewor( to achieveconceptual integrit)@

N %ervices should e a stract? precise Ano overloading? ut allow for pol)morphic servicesB? atomic ut composa le? testa le? etc@

N +ntegration la)er is prefera le A ut not re uiredB to achieve guaranteed deliver)? managedintegration? etc@ and to ena le process orchestration and compleC event processing wherenecessar)@

N %ervices to support 2 integration scenarios shall e identified to allow for more specificsecurit) and %ervice ever #greement A% #B implementation re uirements@

N %ervice level agreement should e defined to support (e) architecture ualities securit)?relia ilit)? performance? availa ilit)? scala ilit)? data ualit)? information fidelit)? etc@

ased upon the a ove,mentioned guiding principles for services design? here is the ta le of integrationservices attri utes to e defined for each of the usiness and ph)sical services of #*+,-.T@ Thecollection of the services attri utes constitutes the integration technical re uirements of #*+,-.T@

Integration Servi$esAttribution Name

Des$ri"tion

Servi$e Identifier !ni ue identifier for each service that is provided ) a logical component@Servi$e Name .ame of the serviceBusiness S$enario Identifier The usiness process to which the service is derived and supports@

Integration Re


43/59


Integration Servi$esAttribution Name

Des$ri"tion

Intera$tion (y"e T)pe of interaction Areal time? atch? event drivenB

Servi$e Choreogra"hy ;efine the need for compleC service interaction etween provider andconsumer? or participate in a stateful usiness process@

Servi$e *"eration #pplied service patterns for service operation Asuch as create? created? etc@ see patterns sectionB@

Information *b e$t The associated information o Fect for the service for input and'or output@

Servi$e essage Si=e The average si e of each message or file@

Servi$e essage &o'ume The average num er of messages or files per time interval@Servi$e Fre


44/59


45/59




12

1

23

3

4


46/59


. 2 AMI-ENT )ata Arc!itecture 6ie(ased on #*+ -.T use cases? four semantic model views are provided

*eter /eading and -vent

#sset and "ustomer +nformation

-nd ;evice "ontrol and To(en

$utage /ecord and or( $rder

The pu lished * %chemas for #*+,-.T services have the detailed attri utes and data t)pesassociated with each of the entities listed in the diagrams elow@

1.1&.1 'eter Rea(ing an( )#ent View This view is a center piece of #*+ data architecture on meter reading and events@ The (e) classes are*eter#sset and -nd;evice-vent'*eter%)stem-vent@ +t provides a data structure for constructing thefollowing messages

*eter/eading

*eter/eading%chedule

*eter%)stem-vent

*eter%tatus

%cheduled-vent

%erviceTo(en

illing;eterminant

-nd;evice-vent

#ctivit)/ecord



12

1

2

3

4

5

6

7

89

10

111213

14

15

16

17

18

19

20

21

22

23

3

4
http://www.smartgridipedia.org/index.php/MeterReadinghttp://www.smartgridipedia.org/index.php/MeterReadingSchedulehttp://www.smartgridipedia.org/index.php/MeterSystemEventhttp://www.smartgridipedia.org/index.php/MeterStatushttp://www.smartgridipedia.org/index.php/ScheduledEventhttp://www.smartgridipedia.org/index.php/ServiceTokenhttp://www.smartgridipedia.org/index.php/BillingDeterminanthttp://www.smartgridipedia.org/index.php/EndDeviceEventhttp://www.smartgridipedia.org/index.php/ActivityRecordhttp://www.smartgridipedia.org/index.php/MeterReadinghttp://www.smartgridipedia.org/index.php/MeterReadingSchedulehttp://www.smartgridipedia.org/index.php/MeterSystemEventhttp://www.smartgridipedia.org/index.php/MeterStatushttp://www.smartgridipedia.org/index.php/ScheduledEventhttp://www.smartgridipedia.org/index.php/ServiceTokenhttp://www.smartgridipedia.org/index.php/BillingDeterminanthttp://www.smartgridipedia.org/index.php/EndDeviceEventhttp://www.smartgridipedia.org/index.php/ActivityRecord


47/59


Documents

AMI-EnT TF - System Requirements Specification - Version 1 - Oct142009 (1)