AMI Architecture Analys

Smart Grid
Reference
Architecture
Volume 1
UsingInformationandCommunicationServicesto
SupportaSmarterGrid
SmartGridrealizationisautilitysjourneythroughaseriesofarchitectures.Itstartswiththe
predominantbusinesssilomodelwithpointtopointinterfaces,toonebestdescribedasa
systemsofsystemsintegratedbysharedservicesandinfrastructure.
SCECiscoIBMSGRATeam
July14,2011
Copyright Cisco Systems, Inc., International Business Machines Corporation, Southern California Edison Company 2011 - All rights reserved.
SmartGridReferenceArchitecture

NOTES
ii

Contents
1.
ExecutiveSummary...................................................................................................................................1
2.
Introduction.................................................................................................................................................2
TheSmartGridArchitecturalChallenge................................................................................................2
3.
SmartGridArchitecture............................................................................................................................3
SmartGridArchitecturalGoalsandPrinciples......................................................................................3
FromaSiloedArchitecturetoaLayeredServicesArchitecture..........................................................7
4.
SmartGridDomainsandCrossDomainFoundationalServices......................................................13
5.
SmartGridReferenceArchitectureViews............................................................................................14
ApplicationServices.................................................................................................................................16
AnalyticsServices.....................................................................................................................................23
DataServices.............................................................................................................................................29
ControlServices........................................................................................................................................34
SecurityServices.......................................................................................................................................40
CommunicationsServices.......................................................................................................................44
Management..............................................................................................................................................53
6.
Summary....................................................................................................................................................59
AppendixA.
SystemofSystemsDesignPatterns......................................................................Appendix1
AppendixB.
ServicesClassesConcepts....................................................................................Appendix11
ApplicationsServices............................................................................................................Appendix11
AnalyticServices....................................................................................................................Appendix19
DataServices..........................................................................................................................Appendix29
ControlServices.....................................................................................................................Appendix33
SecurityServices....................................................................................................................Appendix39
CommunicationServices......................................................................................................Appendix45
ManagementServices...........................................................................................................Appendix60
StructuralModelFrameworkTemplate.............................................................................Appendix65
AppendixC.
SmartGridConceptualArchitectureProject(SCAP).......................................Appendix67
BusinessRequirements.........................................................................................................Appendix67
SmartGridBusinessServices...............................................................................................Appendix76
iii

SmartGridCrossDomainFoundationalServices............................................................Appendix86
AppendixD.
Roadmap&MaturityModel..............................................................................Appendix103
PolicyTimeline....................................................................................................................Appendix103
PursuingtheSmartGridVision........................................................................................Appendix103
MaturityModel....................................................................................................................Appendix107
AppendixE.
GlossaryofTerms................................................................................................Appendix109
AppendixF.
Bibliography.........................................................................................................Appendix115
Tables
Table1TypicalApplicationSpecifications......................................................................................................20
Table2ApplicableApplicationStandards......................................................................................................21
Table3ApplicationTechnologyRecommendations.....................................................................................22
Table4TypicalAnalyticsSpecifications..........................................................................................................26
Table5RecommendedAnalyticsStandards...................................................................................................28
Table6RecommendedAnalyticsTechnology................................................................................................28
Table7TypicalDataServicesSpecifications...................................................................................................31
Table8DataStandardsandTechnologyRecommendations.......................................................................32
Table9TypicalControlSpecifications.............................................................................................................37
Table10RecommendedControlStandardsandTechnology.......................................................................38
Table11AdvancedControlElementsandTechnologies...............................................................................39
Table12SecurityStandardsandTechnologyRecommendations...............................................................43
Table13TypicalCommunicationsSpecifications..........................................................................................47
Table14RecommendedCommunicationsStandardsandTechnology......................................................52
Table15RecommendedManagementStandardsandTechnology.............................................................58
Table16AnalyticsCapabilityMaturityModel...........................................................................Appendix29
Table17MarketDomainBusinessServices.................................................................................Appendix77
Table18OperationsDomainBusinessServices..........................................................................Appendix78
Table19ServiceProviderDomainBusinessServices................................................................Appendix80
Table20GenerationDomainBusinessServices..........................................................................Appendix81
Table21TransmissionDomainBusinessServices......................................................................Appendix82
Table22DistributionDomainBusinessServices........................................................................Appendix84
Table23CustomerDomainBusinessServices............................................................................Appendix86
Table24SecurityServices...............................................................................................................Appendix87
Table25CommunicationsServices...............................................................................................Appendix89
Table26DataManagementServices............................................................................................Appendix95
Table27Glossary...........................................................................................................................Appendix109
iv

Figures
Figure1GWACInteroperabilityContextSettingFrameworkDiagram(GWACStack).......................viii
Figure2NISTSmartGridFramework1.0.......................................................................................................ix
Figure3SCAPRequirementsbyNISTDomain.............................................................................................ix
Figure4SiloArchitectureforEMS/SCADAandMetering/BillingFunctions..............................................7
Figure5EnterpriseServiceBusArchitecture....................................................................................................8
Figure6ConvergedCommunicationArchitecture..........................................................................................9
Figure7SystemofSystemsArchitectureBasedonOpenStandardServices...........................................10
Figure8SmartGridConceptualModel...........................................................................................................14
Figure9LayeredServicesTierView................................................................................................................15
Figure10ApplicationServicesLogicalModel................................................................................................16
Figure11ApplicationServicesStructuralModel...........................................................................................19
Figure12AnalyticsLogicalModel...................................................................................................................23
Figure13AnalyticsStructuralModel..............................................................................................................25
Figure14DataServicesLogicalModel...........................................................................................................29
Figure15DataServicesStructuralModel.......................................................................................................31
Figure16ControlServicesLogicalModel.......................................................................................................34
Figure17ControlServicesStructuralModel..................................................................................................36
Figure18SecurityLogicalModel.....................................................................................................................40
Figure19SecurityStructuralModel.................................................................................................................42
Figure20CommunicationsServicesLogicalModel.....................................................................................44
Figure21CommunicationsServicesStructuralModel..................................................................................46
Figure22ManagementFramework.................................................................................................................53
Figure23ManagementLogicalModel.............................................................................................................54
Figure24ManagementServicesStructuralModel.........................................................................................56
Figure25SiloArchitecture...............................................................................................................Appendix4
Figure26ESBArchitecture...............................................................................................................Appendix5
Figure27AdapterArchitecture.......................................................................................................Appendix6
Figure28ServiceCentricArchitecture...........................................................................................Appendix9
Figure29DisaggregationofaMonolithicSystem.....................................................................Appendix12
Figure30FunctionalServicesOrganization.................................................................................Appendix13
Figure31NetworkOperationsplanningandoptimization......................................................Appendix14
Figure32SmartGridAnalyticsTaxonomy..................................................................................Appendix20
Figure33AnalyticsLatencyHierarchy.........................................................................................Appendix26
Figure34EIMFramework..............................................................................................................Appendix32
Figure35MultiController/MultiObjectiveDesignPatterns(vanBreeman,2001).............Appendix36
Figure36ControlCenterFunctionalArchitecture(IEC,2005)..................................................Appendix37

Figure37HierarchicalControlDesignPattern............................................................................Appendix39
Figure38SecurityThreatsClassification......................................................................................Appendix41
Figure39ConceptualandServicesLayers...................................................................................Appendix45
Figure40CommunicationServicesLayerFunctions..................................................................Appendix50
Figure41TransportServicesConsiderationProcess..................................................................Appendix51
Figure42ConceptualReferenceDiagramforSmartGridInformationNetworks.................Appendix52
Figure43ManagementLayerOrganization................................................................................Appendix62
Figure44SmartGridManagementLayers..................................................................................Appendix64
Figure45StructuralModelTemplate............................................................................................Appendix66
Figure46CommunicationServicesLayerFunctions..................................................................Appendix89
Figure47CaliforniaSmartGridPolicyTimeline......................................................................Appendix103
Figure48SmartGridProjectPortfoliosasaFunctionofMaturity.........................................Appendix104
Figure49Grid1.0EvolutiontoGrid2.0.....................................................................................Appendix106
vi

Smart Grid Reference

Architecture
Reference
Architecture

Wikipediadefinition:
UsingInformationandCommunicationServicesto
SupportaSmarterGrid
Areferencearchitecture
providesaproventemplate
About this document
solutionforanarchitecture
foraparticulardomain.
ThisSmartGridReferenceArchitecturedocumentisdesignedto
addressthechallenges,concernsandquestionsfacingsmartgrid
Aprovenarchitectureis
architectsimplementingsmartgridsolutionsfortheirutility.As
problematicduetothe
withanyreferencearchitecture,itaimstoprovideafoundation
scaleandimmaturityof
forutilitiesinthedevelopmentoftheirparticularsmartgrid
thesmartgriddomain.
architecturesandtoserveasaguideforimplementingspecific
Thereadershouldjudge
featuresdesignedtomaketheirelectricgridsmarter.
theviabilityofthis
Thearchitectsusingthisdocumentmostlikelyworkwithinutility
organizationsintheareasofoperations,generation,transmission
anddistribution,customerservices,informationtechnology,and
researchanddevelopment.
documentbaseduponthe
considerablerealworld
experienceoftheSCE
CiscoIBMSGRATeam.
Additionalaudiencesmayinclude:
Utilityexecutivesneedingclarificationondevelopingacoherentinvestmentroadmaptorequestand
securefundingtoachievetheirenterprisesvisionforasmartergrid.
Utilitiestryingtotransitionfromthespecialized,targetedarchitecturesdevelopedforindividual
businessunitstowardamoreseamless,transparentarchitecturetobeusedacrossallbusinessunits.
Thisarchitectureistomeettherequirementsforoptimalsmartgridbenefitswhilemanagingthe
complexitiesinevitablyintroducedbytherequirementsforasmartergrid.
Standardsorganizations(SDOs,SSOs)andpolicymakersneedingtoclearlyconveyasmartgrid
visionwithenoughdetailtobeactionablebyutilities,regardlessofsize.Asutilitiestransitiontothe
systemofsystemsarchitecturalmodelanumberofchallengesandissueswillariserequiring
assistancefromSDOs,SSOsandstate/federalpolicymakingbodies.
Vendorsprovidingequipmentandservicestoelectricutilities,especiallythosecompanieswhose
productsbecomemorewidelyused.
vii

Foundation Frameworks
Anumberofinformativesmartgriddocuments,whitepapers,andframeworksareavailableonthe
Internet.Thefollowingareespeciallyrelevanttothisreferencearchitectureandworthyofstudy:
ASystemsViewoftheModernGridbytheNationalEngineeringTechnologyLaboratory(NETL,2007)
thiswhitepaperinspiredmanyoftheconceptsexpandeduponinsubsequentpublications.It
identifiesfiveprimaryinterdependentelementsdesirableforamoderngridanddefinesthoseconcepts
includingthesevensmartgridprincipalcharacteristicslistedinsection2.
TheGridWiseInteroperabilityContextSettingFrameworkbytheGridWiseArchitectureCouncil
(GWAC,2008)aworkthatfocusesontheinterfacebetweentwoormoreinteractingpartiesand
providesaframeworkfordiscussingtheintegrationofcollaborativeprocessesandindependent
automationcomponents.Itidentifieseightinteroperabilitycategoriesdefinedbytheframeworkand10
crosscuttingissuesapplicableineverycategory.Thecategoriesaretaggedastechnical,informational
ororganizational,andarestackedaccordingtotheirincreasinglevelofabstraction[Figure1].
Figure1GWACInteroperabilityContextSettingFrameworkDiagram(GWACStack)
Whilethisstructureisnotusedtoorganizethereferencearchitecturedescribedinthisdocument,it
providesthebasisforthestructuralmodelspresentedinthereferencearchitecturalviewsinsection5.
TheNISTFrameworkandRoadmapforSmartGridInteroperabilityStandardsbytheNational
InstituteforStandardsandTechnology(NIST,2010)aconceptualmodelcreatedtosupportthe
planningandorganizationoftheinterconnectednetworksexpectedintheSmartGrid.TheNIST
approachdividedtheSmartGridintothesevendomainsshowninFigure2.
viii

Figure2NISTSmartGridFramework1.0
In2010NISTcommissionedtheSmartGridInteroperabilityPanels(SGIP)SmartGridArchitecture
Committee(SGAC)toleaditsSmartGridConceptualArchitectureProject(SCAP).TheSCAPworking
grouptooktopdownandbottomupapproachestoestablishafoundationforthedevelopmentof
smartgridbusinessrequirements.
TheSGACstopdownapproachinvolvedareviewofallmajorfederalenergylegislationsignedinto
lawsince2000,morethan9,500pages.Reviewofthesedocumentsresultedintheidentificationof400
goals.Thebottomupeffortsreviewedmorethan600usecaseswrittenbyavarietyofindustry
organizations,includingmorethan20systemsrequirementdocumentsproducedbyindustryworking
groups.Thebottomupreviewproducedmorethan8000businessrequirementsfortheSmartGrid.
Figure3illustratesthedistributionofthesmartgridbusinessrequirementsbydomain.(SGIPSGAC)
Figure3SCAPRequirementsbyNISTDomain
ix

Thispreliminaryworkcreated400familiesofrequirementscoveringthesevenNISTdomains.These
highlevelbusinessrequirements(availableontheNISTwebsite)encompasstheentireSmartGrid
frommarkettocustomerfrombulkgenerationtodistribution.TheyformthebasisofwhattheSmart
Gridrequiresfromabusinessstandpointandtomeetfederalgovernmentsenergygoals.0providesa
listoftheSCAPBusinessRequirementsandServices.
SmartGridReferenceArchitecturebytheP2030WorkingGroup(IEEE)thisdocument,expectedin
thethirdquarterof2011(draftpublishedinMarch2011),willprovideguidelinesforsmartgrid
interoperability,includingadiscussionofbestpractices.TheP2030guidewillalsoprovidea
knowledgebaseaddressingterminology,characteristics,functionalperformanceandevaluation
criteria,andtheapplicationofengineeringprinciplesforgridinteroperabilitywithenduse
applicationsandloads.AtfirsttheSCECiscoIBMreferencearchitectureteamexpressedconcernon
thepotentialoverlapbetweentheP2030guideandthisdocument,butafterathoroughcomparisonof
thetwodrafts,theconsensusisthatthisreferencearchitecturemerelycomplementstheP2030guide.
WhereastheP2030Guidedocumentsacatalogofinterfaces,thisdocumentaddressesthearchitecture
andfoundationalservicesnecessarytodevelopSmartGridsystems,interfaces,andprocesses.
ThealertreaderwillnoticethisdocumentisentitledVolume1.Itincludesasetofviewsonsmartgrid
architecturelargelywrittenfromthepointofviewofsystemintegration.Itisexpectedtobeauseful
companiontoIEEEP2030.AsIEEEP2030cataloguessmartgridsysteminterfaces,theSGRAVolume1
cataloguessmartgridsystemservices.Similarly,theNISTSGCAlistselementalsmartgridfunctions
(unitoperations);theNISTFrameworkandRoadmapforSmartGridInteroperabilityStandards
identifiesrelevantsmartgridinterfacestandards;andtheGWACInteroperabilityContextSetting
Framework,asacompaniontotheNISTFramework,providesrigoraroundtheconceptof
interoperability.Eachcontainsmorethandescribedabove,astheirauthorswillattest,butthese
characterizationsarehelpfulinframingeachdocumentinthecontextoftheentireset.
Eachoneofthesedocumentsisavaluablecontributiontothefieldofsmartgridarchitecture,and
smartgridarchitectsarestronglyurgedtostudyeachofthem.However,afterthisdocumentwas
completed,theteamsensedasetofarchitecturalviewswasneededtotiethesecontributionsintoa
unifiedwholethatwouldmaketheSGRAactionableinboththeneartermandthroughoutthegeneral
smartgridutilitytransformationjourney.ThatiswhythisdocumentwaslabeledVolume1,tobe
followedshortlybyVolume2.TheVolume2documentwillsynthesizethevariousexpositionson
interfaces,standards,andservices,aswellasmeasurement,datamanagement,control,
communications,andsecurityfromtheabovementionedSmartGriddocumentsintoapractical
consolidatedarchitecturalguiderepresentinghowbesttoimplementsmartgrids.Volume2willalso
tietogetherenergydeliveryelementsofparticularimportanceasthesmartgridscalesup,resultingin
interactionsofincreasingcomplexitywithsimultaneousimpacttoonceindependentutilitytiers.
Smart Grid Reference Architecture
1.
Executive Summary
The Smart Grid Reference Architecture is intended as a template for Smart Grid architects to follow as
they build Smart Grid Information and Communications Technologies (ICT) architecture for their
utility, regardless of the architects specialty (transmission, distribution, metering, IT, communications).
The goal of this document is to accelerate the construction of a utilitys Smart Grid architecture and
implementation strategy by leveraging the reference architecture constructs contained therein.
This reference architecture recognizes the need to logically transition from the existing, largely ad hoc
nature of the typical utility grid architecture to one based on open interoperability standards, and
designed to manage complex solutions while facilitating the integration of emergent smart grid
capabilities. It explores three migrations across four transition states and takes into consideration the
many years required to develop sound recommendations for smart grid architecture.
Security is an integral element of the grid ICT architecture and a multi-layered approach is advocated,
including both physical and ICT-based security mechanisms. Layering smart grid services using the
proposed system-of-systems architecture should minimize the stranded costs utilities invest in one-off
solutions. A layered service-centric architecture also minimizes the expense, configuration headaches,
and management complexity a utility faces pursuing a point-to-point interoperability architecture.
Another aspect emphasized in this reference architecture that could lead to considerable cost and time
savings for utilities are the implementation of data services and data management. Greater access to
and use of data is critical to the realization of a grids ability to accommodate new capabilities while
improving security, reliability and quality.
A significant portion of this reference architecture is dedicated to discussing common foundational
services and the corresponding architectural views, important for maintaining the high levels of
performance and efficiency required by a modern grid ICT. Recognizing that some services are best
centralized while others must reside primarily within grid-state aware edge components, this
discussion also explores the best central-versus-edge mix for deploying various domain components.
This Smart Grid Reference Architecture was produced by a team of architects from Southern California
Edison (SCE), Cisco Systems, and IBM. Its development spanned a period of nine months (July 2010
through March 2011) and involved a number of face-to-face team workshops and web-based meetings.
An external review by EnerNex added additional insight and content.
Executive Summary 1
2.
Introduction
The Smart Grid Architectural Challenge

The January 2007 white paper, A Systems View of the Modern Grid, by the U. S. Department of Energys
(DOE) National Energy Technology Laboratory (NETL) identifies seven smart grid characteristics:
self-healing
able to motivate and engage the customer
resistant to attacks
provides power quality suitable for 21st century needs
accommodates all generation and storage options
enables markets
optimizes assets and operates efficiently
There are a number of Smart Grid definitions, but no matter which is used, there is little dispute over
the vastness of program scopes faced by smart grid architects. Incorporating information and
communications technologies into what the National Academy of Engineering calls "the greatest
engineering achievement of the last century" (NAE, 2011) will be the one of the most complex human
endeavors ever undertaken. This robust engineering achievement must be extended to support
enhanced situational awareness (via synchrophasors), industrial-scale energy storage, distributed
(dispersed) energy resources, improved field worker effectiveness (via wireless communications and
automated asset management), remedial action scheme expansion, substation automation, volt/VAR
optimization, fine-grained demand response, distribution automation, improved power quality, power
disturbance self-healing, micro-grids, personal and fleet electric vehicles, automated metering,
premises area networks, enhanced customer energy management, power grid congestion-management,
advanced integrated command and control, transmission/distribution smart sensor deployment, very
low-latency protection communications, and not yet identified technologies that are certain to emerge
as the Smart Grid matures. All this must be accomplished as the world's largest machine, the electric
grid, continues to operate unabated, while maintaining present or improving reliability. In addition,
embedded security measures must be built concurrently to marginalize the possibility of successful
cyber and physical attacks from an ever-growing number of threats, and prevent unauthorized use of
customer personal data and energy usage information. Finally, there are demands from regulators,
political leaders, and social groups to make the grid smarter quickly, while addressing environmental
objectives and keeping electric rates low.
Introduction 2
3.
Smart Grid Architecture
The Smart Grid architectural challenge is a daunting one. This is especially true for those within the
electric utility industry known for their conservative approach toward incorporation of ICT-based
systems to help run and manage the electric grid. Most automated grid systems in use today were built
to address narrowly targeted requirement sets. As a result, a typical utility has a plethora of purchased
and homegrown systems stitched together over the last three decades with point-to-point interfaces.
This approach is unsustainable for a utility to efficiently and effectively implement smart grid
capabilities over the next two decades. This document presents a different approach to utility system
design and integration, using newer paradigms to deal with complex and legacy system integration.
Smart Grid Architectural Goals and Principles

The next two decades will see the Old Grid evolve into a Smart Grid as legacy grid infrastructure
is merged with the latest ICT. This will put extraordinary demands on the ICT architecture; therefore,
high-level goals and principles are needed to guide the smart grid architects tasked with developing
any aspect of an organizations grid architecture. Additionally, a highly flexible, adaptive Enterprise
Smart Grid architecture is critical for this transition to be successful. The architecture must support
existing ICT infrastructure operations and be able to keep infrastructure complexity manageable as
new smart grid capabilities are added.
How a utility defines its smart grid architecture will vary according to their organizations particular
needs. Some possible goals are:
Facilitate bridging new and emerging information and communications technology to legacy
architecture over extended time periods (technology roadmap).
Manage the increasing complexity of ICT needed to support smart grid implementation.
Align technology usage with the utilitys smart grid strategic objectives.
Provide guidance on how packaged solutions can support the smart grid architectural vision.
Facilitate the communication of the utilitys smart grid strategy and plans across the enterprise
Help sell the utilitys smart grid vision to business unit leadership, IT management, suppliers,
regulatory agencies, contractors, etc.
Help stakeholders (application developers, IT managers, and end users) plan, budget, implement
and use smart grid information and communication technologies.
Make the utility smart grid architecture easily accessible and transparent.
Support the interactions of processes, tools, technology and people to achieve business ICT goals.
Once a utility has defined its smart grid architecture goals it should develop a set of written principles
to provide high-level direction during architecture development. Some principles a utility may
consider important are:
Smart Grid Architecture 3
1.
2.
3.
4.
5.
Design for simplification by exploiting strategic assets

Motivations:
Reduce complexity and cost
Let the enterprises employees focus on customer, not on internal processes
Implications:
Establish single architecture control point for requests to expand the portfolio
Finish what is started to enable legacy sunsets
Reduce complexity and low value work steering investment & effort to high value activities
Reuse process, data, and ICT assets whenever appropriate
Motivations:
Accelerate business capability delivery
Reduce cost
Increase enterprise consistent use of best practice designs
Increase responsiveness to regulatory requirements
Implications:
Must identify, adopt and reuse process, data and ICT assets for enterprise wide use
Must promote business modularity from strategy through deployment
Must direct funding to develop and adopt best practice assets
Use off-the-shelf rather than build solutions
Motivations:
Reduce cost and time to market
Improve time to market
Implications:
Understand what off-the-shelf solutions exist and what processes they support
Re-engineer the business process or model to use off-the-shelf products and services
Use Business Process Driven development to move toward a process-centric organization
Motivations:
ICT development will be driven by Enterprise Business Process
Process will drive continual improvement across the enterprise
Use business priorities to drive technology adoption
Continually improve ICT effectiveness and efficiency
Facilitate cross enterprise integration
Implications:
Align enterprise processes with enterprise strategy
Close business-IT partnership with IT engaged early in the solution development process
Ongoing maintenance/management of enterprise business processes
Base architecture on total cost of ownership (TCO)
Motivations:
Provide a common approach for dealing with applications
Optimize operational manageability while making key business and technology decisions
Minimize cost of complexity while making these decisions
Free up resources from low value to higher business value application through optimization
6.
7.
8.
9.
10.
Implications:
Elimination of low value applications at every possible opportunity
Avoid introduction of new low-value applications for short lived business requirements
TCO based approach to be used for major technology decisions
Ensure business decisions are based on information from appropriate trusted data sources
Motivations:
Achieve highest degree of integrity and validity for business decisions
Minimize IT costs for managing and maintaining data
Enhance ease of doing business by eliminating manual data integration, normalization, etc
Implications:
Practitioners more likely to know what trusted sources exist, and which ones to use
Solution teams realize reduced cost benefits using appropriate trusted sources
Develop data models and a data dictionary for the entire portfolio
Motivations:
Improve operational excellence
Reduce unnecessary transformations of data and related re-work
Enable meta data sharing for exchange and integration purposes
Improve future system design and programming projects
Improved documentation and control mechanisms
Implications:
Project teams bound by data model/dictionary governance processes
Close collaboration between business and IT stakeholders
Easy access to data model/dictionary given to designers and programmers
Master data element created from one trusted source
Motivations:
Increased data integrity and reliability
Cost reduction for managing information and data quality
Implications:
Consistently invest in, and comply with, the trusted sources architecture
Processes engineered to maintain consistent master data management and consumption
Only store copies of data within approved trusted sources
Motivations:
Achieve highest degree of integrity and validity for business decisions
Minimize ICT costs for managing and maintaining data
Enhance ease of doing business by eliminating manual data integration, normalization, etc
Implications:
Practitioners more likely to know what trusted sources exist, and which ones to use
Solution teams realize reduced cost benefits using appropriate trusted sources
Data currency is in line with business expectations.
Implement data quality plans for all business solutions
Motivations:
Maximize data integrity and validity for business operations and decision making
Avoid operational disruption due to data errors
Reduce cost and complexity
11.
12.
13.
14.
Implications:
Real cost implications associated with avoidance of data quality plans
Data quality easier to implement and sustain
Design solutions that provide measurable business performance and value
Motivations:
Maximize ICT ROI
Focus design and development teams on business success goals
Validate the ICT governance model
Achieve measurable performance gains
Implications:
Link strategy to business case and customer requirements to metrics
Enable collection, analysis and reporting of metrics, actual to plan
Design generation of metric data into solutions
Establish process-level Key Performance Indicators
Enable applications for reuse and portability as services
Motivations:
Ability to quickly add, modify, remove or replace service functions
Reduction of integration expense and partner boarding costs
Facilitate the reuse of strategic applications and business functions
Enable application and function relocation for process or cost effectiveness
Improve support of acquisitions and divestitures
Reduce point-to-point integration solutions
Implications:
High return investment hotspots emphasized
Centralized support for design enablement
Enterprise group assigned to enhance competency on standards and references
Portability design based upon being agnostic on platform, location and virtualization
Adoption of service modeling methodology
Design and test solutions to satisfy non-functional requirements
Motivations:
Stabile platforms supporting the enterprise business
Ensured Return On Investment
Implications:
Need to understand the target audience and expected workload of new solutions
Infrastructure impact of new solutions known early in the design cycle
Infrastructure constraints considered in analysis of growth markets
Design solutions to make use of infrastructure common services
Motivations:
Reduction of infrastructure duplication and cost
Less complexity for the end user
Improvement of system interoperability
Implications:
Re-use of existing common services, reduction of new service construction
Need for common services to be robust and user-friendly
From a Siloed Architecture to a Layered Services Architecture

Architectural evolution can be defined as how a typical utility implements its smart grid
transformation in stages. A white paper discussing this evolutionary process in depth can be found in
Appendix A. For the purposes of this paper the process has been divided into four stages.
Stage One: The predominate architecture of grid systems is a collection of silos. Figure 4 is an example
of silo architecture for EMS/SCADA and metering/billing functions. Different functions (SCADA, EMS,
DMS, OMS, Billing, and Metering) use disparate information with minimal interaction.
Figure 4 - Silo Architecture for EMS/SCADA and Metering/Billing Functions
The silo architecture worked well for utilities for decades - each silo served the needs of a business unit,
each having very different needs. Utilities operated efficiently with little integration across silos. The
silo solution, however, is not sustainable to support the Smart Grid. The number of stakeholders
needing real-time data from every silo cannot be support long-term point-to-point interfaces.
Stage Two: Some utilities have taken the next step in smart grid evolution the integration of the back
office and applications via a common service bus, such as the enterprise service bus architecture shown
in Figure 5 . This is often a difficult and costly process. In addition, service-bus integration requires
enforcement of standards on data models and ICT services. Without the enforcement of standards, the
service bus is simply a shared communication device with little resolution of silo weaknesses.
Figure 5 - Enterprise Service Bus Architecture

Stage Three: The next step towards a unified, shared infrastructure is realized by moving away from a
series of single-purpose networks to a converged communication infrastructure [Figure 6]. This shared
infrastructure enables as-needed data transfer from end points to consuming applications in
accordance with stated requirements (quality of service, criticality, bandwidth, latency, etc.).
Figure 6 - Converged Communication Architecture
Stage Four: The ultimate Smart Grid ICT architecture is converging on layered, open standard services
architecture. It provides capabilities across functional and organizational boundaries; from a
data/control center to edge devices and data consumers (applications and end users).
Figure 7 System-of-Systems Architecture Based on Open Standard Services
The system-of-system architecture shown in Figure 7 supports the following capabilities:

Components can be added, replaced or modified without affecting the remainder of the system
Components are distributable (can run on arbitrary servers)
Components communicate with each other by messages or service invocations
Component interfaces are defined using standard metadata
Component interfaces are discoverable by application developers
One component can replace another with the same interface
Services can be used multiple times by disparate applications or the same application.
Achieving such smart grid capabilities requires a great amount of interaction among systems. For
instance, most utilities rely on customers to report an outage; in the future, the advanced metering
infrastructure (AMI) will interact with the outage management system (OMS) to predict and confirm
outages. Once OMS confirms an outage, the distribution management system (DMS) calculates the
necessary switching steps needed to isolate the fault area and restore service in a timely manner. The
field workforce will directly interact with the OMS and DMS, responding to automatically issued work
orders and providing a detailed estimate of restoration time. Meanwhile, the customer can be notified
of the outage status in real-time via user-defined means (cell phone, web, etc.). As the capabilities of the
communication infrastructure advances, additional intelligence will be deployed closer to the
customers premises, allowing pro-active decisions to be made locally to avoid or minimize outages,
while informing the utility systems and operators of the locally implemented actions for potential
adjustment and optimization of energy resources.
The Smart Grids capabilities will need to be facilitated by an architecture that enables the connected
devices and systems to securely interact and exchange information and control. Field devices and
electrical equipment should not only publish data to help improve real-time monitoring of the electrical
grid, they will need to subscribe to other devices' information as well, allowing the devices to respond
to control signals and data requests issued by applications and systems responsible for grid monitoring
and control. This dispersion of data across the grid poses a significant challenge to utility data
management. The quality of the data is also a concern, requiring intelligent devices to be properly
configured and maintained. Device configuration control is best performed by a common management
tool tasked with component provisioning and de-provisioning. Even though the future communication
infrastructure is expected to be more robust and feature high performance communication channels,
the large amount of data, data sources and data consumers requires grid intelligence to have
decentralized and centralized aspects:
Decentralized embedded systems and applications will be responsible for analysis, filtering and
taking particular actions based on the data provided by local field devices.
Centralized systems will be responsible for coordinating the decentralized systems, ensuring the
overall reliability and stability of network.
With applications and systems physically dispersed into the network to lower the cost of deployment
and maintenance, each component of the Smart Grid system-of-systems will be required to satisfy four
key principles of layered services architecture:
1.
2.
3.
4.
Individual components can be added, replaced or modified without impact to other systems.
Components are distributable, communicating by messages or service invocations.
Interfaces between components are discoverable and leverage standard metadata
Component services can be easily reused by different applications.
While reusable and shared services reduce costs and minimize complexity, they also enable faster
deployment of new applications. This will be crucial for the utility to efficiently adapt to evolving
regulatory mandates.
To transition from a Stage 1 silo architecture, or a Stage 2 partially integrated architecture to a Stage 3
or Stage 4 layered services architecture, the utility must define and plan for strategic investments in
modernizing its infrastructure and systems. To be successful, each planned investment must be
reviewed and assessed from an enterprise standpoint to ensure investments help the organization
transition toward the future Smart Grid Architecture. Adoption of shared services, standards and a
unified infrastructure need to be understood as intrinsic requirements for each planned investment.
A transition plan some companies have adopted is to first move from a siloed architecture to
middleware integration architecture. This is followed by a gradual migration to an open-standards
based architecture, incrementally developing and adopting standards and common services. Each
increment helps move the enterprise toward the vision of this Smart Grid Reference Architecture. The
timing of the transitions is often documented by a smart grid roadmap. Appendix D presents one
technique for constructing a roadmap. It also provides a brief discussion on the Smart Grid Maturity
Model (SGMM) sponsored by Carnegie Mellon University.
The smart grid architect should apply the system-of-systems architecture patterns described to first
develop use cases and a comprehensive set of requirements. These can then be used to develop the
shared services and target physical architectures needed to support the desired capabilities across the
utilitys smart grid.
4.
Smart Grid Domains and Cross Domain Foundational Services
Seven domains comprise the conceptual model described in NIST Framework and Roadmap for Smart Grid
Interoperability Standards, Release 1.0 (NIST, 2010). A smart grid has inherent power flow and grid state
complexity embedded primarily within this models Operations domain. This SGRA recommends two
additional domains should an architect wish to explicitly address these complexities. In addition, the
SGRA supports the concept of foundation-level services used by multiple domains.
The NIST smart grid conceptual model domains are:
Customer: the functional needs within the customers premises, including the ability to generate,
store, monitor and control the electricity usage of customers (both residential and commercial).
Market: the functional and operational need for operators and participants in the electricity market.
This is where efficient matching of energy production and consumption is performed.
Service Provider: the functional needs of organizations offering or leveraging utility services. These
include power producers, distributors, regulatory agencies, banks, credit bureaus, etc.
Operations: managers of electricity movement, responsible for the smooth operation of the grid
Bulk Generation: the needs of power generation entities producing more than 300 megawatts.
Transmission: the applications and tools to deliver bulk electricity over long distances, such as a
Regional Transmission Operator or Independent System Operator (RTO/ISO).
Distribution: often considered the primary focus of smart grid changes, offers all the required
functional services to electricity distributors to and from customers, as well as the services to
manage distributed energy resources, including energy storage and plug-in electric vehicles.
Supplementing the NIST-defined domains, the following are potential expansions to the architects
smart grid conceptual model:
Balance required for the dispatch of distributed energy resources and demand response due to
their roles in balancing supply vs. demand on the grid; increasingly data interaction between the
utility, the consumer and the balance authority will be needed in the Smart Grid environment.
Interchange the visibility onto grid state required to address increased power flow complexity,
placing requirements on smart grid systems for data communications and management.
Cross domain foundational services are those that two or more domains rely upon and therefore need to
be interoperable across domains. For example, a system having one form of encryption in one domain
and a different one in another will lead to problems when the two exchange information, thus causing
additional work to correct the problem in the final implementation. This could be avoided by a single
encryption method used by all systems as a cross domain foundational service.
Cross domain services are broken down into six groups: Analytics, Data, Control, Security,
Communication, and Management. Discussions on each service group can be found in Appendix B.
Architects and others interested are encouraged to study this appendix for more detail.
Smart Grid Domains and Cross Domain Foundational Services 13
5.
Smart Grid Reference Architecture Views
The comprehensive, end-to-end, high-level architecture needed to support the utility business domains
and common enabling services discussed in Section 4, uses a model that assumes a service-oriented
governance process exists supporting the intrinsic characteristics of layered services architecture. The
models seven business domains are each logical groupings of business capabilities providing related
business functions while requiring similar skills and expertise. These match the domains identified by
NIST in Special Publication 1108, NIST Framework and Roadmap for Smart Grid Interoperability Standards,
Release 1.0 (NIST, 2010).
These functional areas form the basis for defining the boundaries of ICT capabilities and systems, and
provide a means to classify components and services. Common enabling services provide a variety of
services for systems and subsystems to accomplish business functions. Governance provides a
framework to define the relationships and processes used to direct and control grid activities, as well as
the actions, authority and metrics used to realize business benefits while balancing risk versus reward.
The left side of Figure 8 shows the seven NIST utility domains as distinct logical groupings of common
capabilities. A utility may elect to combine some domains (i.e. distribution and transmission) and plan
a single logical infrastructure to support the Smart Grid. In addition, utilities opting for interactions of
Smart Grid elements with the Balance and Interchange domains will need to extend this model.
Figure 8 - Smart Grid Conceptual Model
The top of Figure 9 names five smart grid end-state architecture tiers (user/device, channel,
presentation/edge, integration, services). In this tiered architecture, data flows from left to right (and
Smart Grid Reference Architecture Views 14
back) through the various tiers, each with layered service groups or capabilities. The large box at the
bottom of the figure (spanning the three right tiers) represents the cross domain foundational services
discussed in section 4 above.
Figure 9 - Layered Services Tier View
Each services group discussed in the following subsections provides a:

Logical architecture diagram
Structural architecture diagram
Table of typical architectural specifications for the service group
Table of relevant standards for the service group
Table of relevant technologies for the service group
Application Services
Smart grid applications services provide functionalities for the presentation tier, the services tier, and a
mechanism to integrate various applications through the integration tier as depicted in Figure 9.
Applications consume services to present secure, timely, relevant, and understandable information in
response to a validated stakeholder request.
Applications Services Logical Model

The Application Services Logical Model [Figure 10] is made up of three views, (1) application component,
(2) application services stack and (3) application synergy.
Figure 10 - Application Services Logical Model
The application component view depicts in block format the primary functional components used to
build the architecture being described. This model follows the IEC 61968 and 61970 specifications, most
notably the Interface Reference Model (IRM) categorization of functional components necessary for
smart grid transformation within a utility.
The application services stack view defines the services required by smart grid applications. Due to the
number and broad range of services consumed by applications, the list is best understood by grouping
the services into broad service types. The stack services are therefore divided into four categories:
Foundation services many key technical foundational services are required by the application
architecture tier. Used throughout the architecture, these services are leveraged to varying
degrees by other technical and functional services. For example, the enterprise service bus is one
of the foundation services used throughout the architecture.
Core services the primary service stack for the application architecture are service governance
through a services registry and repository, a message gateway, web Integration services, a state
machine, and a business process execution language (BPEL) engine and workflow. These core
services provide baseline capability in the application tier.
Integration services services such as enterprise services bus, rule engine, the Common
Information Model (CIM) binding, service orchestration, security agents, and policy cache
provide the integration needed between the functional services and other architectural tiers.
Support services the application architecture utilizes common support services for security,
communication, data management, smart grid management, analytics, and control. Support
services underpin application architecture and are re-used extensively in each services group.
The application synergy view [Figure 10, upper left] depicts some of the key issues faced by an
enterprise architect while architecting the Smart Grid application architecture. The data generated by a
device or end point may serve multiple consumers in a format specific to each consumers needs. The
application architect can use the model to identify re-use opportunities for data and integration
services as smart grid application functionalities are built. Potential synergy prospects are those with
similar paths through the various tiers.
The tiers and how they relate to the Smart Grid are:
Source Tier: Different data generation sources (sensors, feeder devices, etc.) in the Smart Grid
produce the four different data classes (telemetry, waveforms, events, user data) shown in the
application synergy model portion of Figure 10. This tier is comprised of the various parameters
used to differentiate sources. There are important architectural considerations when selecting the
(1) components to process the data, (2) communication infrastructure to transport the data, and
(3) security services needed to protect the data. The frequency at which a source generates data
is dependent on the purpose of the data. For example, if data is expected to be used for
calculating grid state, the data generation frequency will be high. If the data represents
consumer usage data, the frequency is much less perhaps once every several minutes. Thus the
purpose of each datum and source needs to be analyzed, and only then should relevant
architectural components be selected to implement the requirements.
Data Classes: There are four high-level data class types supported in Smart Grid architecture.
Waveforms data represent values of electrical measurements such as current, voltage, phase, etc.
Telemetry data represent readings generated by field sensors. Event messages can be generated
by field crew, distributed energy resources (DER), automated demand response (ADR), etc.
Usage data is generated by consumer smart meters. These data classes are presented to ensure
the application architecture supports all data classes, and to help the architect choose the best
integration pattern.
Application Services: This tier represents how different components must interact to provide
desired business functionality. Different data classes connect to the Smart Grid infrastructure
through the enterprise services bus (ESB). This provides multiple capabilities, such as handling
request/response, publish/subscribe (event) processing, event interception, gateway
communication, business rules, CIM binding, policy caching, etc. The core ESB features
provided (protocol transformation, routing, etc.) allows the service bus to act as a mediator
between the data source and consumer. Web integration services can consume usage data and
provide data to customer service hosted by a third party or utility partner. Similarly, third party
consumers may connect to smart grid applications through gateway services. Applications often
require workflow, CIM binding, access to an external rules engine, and service discovery for
building functional capabilities. Refer to Appendix B for more detail on application services.
Consumers/Processes: These are the high level business functions identified in the IEC IRM.
These business functions are developed using application services to collect and process source
data for end-user consumption. Edge presentation services may be used for some consumers
while others are supported by application servers via the ESB. Functional components
developed on application servers make use of rules engines, workflow, process services, BPEL
engines, state machines, complex event processing, gateway services, etc. Web integration
services are used to develop support services and user-generated content, including derivative
applications from pre-existing sources (mashups).
Application Services Structural Model

The application services structural model [Figure 11] is provided to help the smart grid architect
consider how to best deploy the various application services using a stylized representation of a typical
utility network infrastructure. At the top of the model are elements needed to support external agencies
(regulators, interchange and balancing authorities, etc.). At the bottom are the application services
needed by premise devices (smart appliances, PEV chargers, building energy managers, etc.). In
between are a dozen other tiers where application services may be located to support residing devices
and functionality. A self-describing template used for this model is on the last page of Appendix B,
Services Classes Concepts. Included are descriptions of all fourteen tiers used in the model.
Figure 11 - Application Services Structural Model
Applications Architecture Specifications

Each smart grid application will have a list of specifications for the application architecture to support.
This topic is, however, does not address every specific smart grid application. It is instead intended to
be a discussion of common specifications for an abstracted collection of smart grid applications.
Table 1 is therefore a list of general specifications with potential relevance to a smart grid application.
The justification for each is provided to enhance the readers understanding of each specification.
The table does not include detailed business or technical requirements a specific application would
fulfill. Each utility will build a detailed application requirements list as part of any smart grid project.
Table 1 - Typical Application Specifications
Specification
Justification
Application access shall be tightly controlled.

The application architecture shall use common
services instead of building redundant services.
The application infrastructure shall leverage
virtualization at the data center.
The application shall be deployable in a distributed
fashion. Places in the grid for application
deployment are illustrated in an hierarchical model.
Application infrastructure must be rugged for
applications that are deployed on substation,
feeder, and premises area.
The application shall use common auditing/logging

capabilities to support comprehensive management
architecture.
Applications architecture shall promote open
standards and avoid vendor lock-in.
Whenever possible, management of systems shall
be centrally and uniformly managed.
Business rules (i.e., implementations of the policies
and practices of a business organization)
externalization shall be supported.
Any commercial-off-the-shelf (COTS) application
package used shall be minimally customized.
A comprehensive design, build and run platform
shall be used to support implementation of the
Smart Grid application architecture.
All information shall have defined authoritative
sources (information stewards).
A comprehensive architecture governance
mechanism shall be used during application
architecture development.
As needed, common services shall be developed for
communication, security, and data architecture as a
precursor to the development of the application
services architecture. (similar to second spec listed)
Enterprise business service definitions shall be
managed and enabled for automatic discovery.
Applications must be protected from unauthorized access.

Common services such as authentication and authorization,
communication, and management services, if reused properly can
drastically cut costs.
Reducing the consumption of key resources such as energy and
personnel while improving the utilization of IT hardware and
software can yield environmental as well as financial benefits.
Each location where data is generated or information is consumed is
a location candidate for the appropriate application. Communication
network elements hosting additional software are also good
candidates, since communications elements generally exist where
data sources and consumers reside. By making use of such elements
to host applications, it is possible to provide the benefits of
distributed architecture while minimizing the number of devices to
be managed and maintained. Zero-touch deployment is crucial.
Event logging is necessary to support post mortem analyses of
various kinds. With the volume of events generated by a Smart Grid,
management of the event logs is a large issue; therefore, care must
be taken for selecting consistent mechanisms across the enterprise.
Proprietary applications are difficult to integrate and generally
defeats system-of-systems primary design principles.
Integration with the management services architecture is necessary
to make distributed application architecture operations feasible.
Decoupling and externalizing business rules can provide a number of
advantages: variable logic can easily be changed, duplication of logic
at multiple places can be avoided, and discovery of and fixing
miscreant rules can be simplified.
Minimum customization of COTS allows version upgrades and
enhancements.
Application development lifecycle management through integrated
development platform enables disciplined application development.
Data needs to be made available in a timely and accurate form, and
must be captured and validated.
Architecture governance enables fundamental aspects of service
oriented architecture, which provides inputs vital to the development
of the application architecture.
This is vital to the development of the application architecture, since
common services are significant providers of support functions.
Sometimes a chicken or egg conundrum, however, for enterprises
with an immature SOA infrastructure.
Basic service repository mechanisms can reduce integration cost and
help in business flexibility.
Specification
Justification
Enterprise class service: development of services

used across the enterprise shall trump the
development of similar or duplicative services
provided solely to a particular organization.
For low latency applications, implementation shall
be located at or very near the data source(s) and
the primary outputs destination(s),
Software and hardware shall conform to defined
standards that promote interoperability for data,
applications, and technology.
Unique version namespaces shall be used for

service versioning.
Modular design shall be used wherever possible
(moving away from monolithic systems).
Multiple channels supporting client application

delivery shall be available, with an ability to tailor
the delivery mechanism to the client.
ICT shall plan, design, and construct for growth and
expansion of services across the Smart Grid.
The federated architecture shall promote reduced
complexity and enable integration to the maximum
extent possible through adoption of standards.
The architecture shall be based on a design of
services mirroring real-world business activities
managed by the enterprise business processes.
Duplicate capability is expensive to build and maintain. It also poses

challenges in maintaining data integrity.
This is a direct consequence of the distributed nature of power grids

and their control systems. The requirement avoids hops to and from
remote processing centers. Embedded processing is used, but the
actual application is downloadable.
Standards help ensure consistency, thus improving the ability to
manage systems, improve user satisfaction, protect existing IT
investments, maximize return on investment and reduce costs.
Standards for interoperability help ensure support from multiple
vendors for an asset, and facilitate supply chain integration.
Application programming interface versioning is a common problem
in the design of any distributed system, and services are no
exception, they must be versioned for correctness and manageability.
Modular design provides flexibility in design and helps in scaling a
solution. A solution's overall functionality can be decomposed into
smaller functional building blocks and, ideally, perform only one
conceptual function.
Consumers, partners and field force want channel of service delivery
to fit their individual preferences and circumstances. Having multichannel access protects against single point of access failure.
Application architecture and design must plan for growth to provide
business flexibility.
Complex application systems with many data and transactional
functions are difficult to manage and risky to change. Applications
with tightly coupled modules risk creating a dependency failure.
Service orientation delivers enterprise agility and boundary-less
Information Flow.
Architecture Standards and Technology Recommendations

The following tables of architecture standards and technology recommendations are provided to the
smart grid architect as references. Over time, however, innovations will inevitably diminish their
completeness. The architect should always research the latest information on these topics, but these
should provide a good starting point. Table 2 lists the most important 2011 standards, while Table 3
lists technology recommendations, with brief explanations of their purpose or relevance.
Table 2 - Applicable Application Standards
Standards
Purpose/Relevance/Comments
Distributed
Network Protocol
(DNP3)
IEC 60870-6
Defines a set of communications protocols used between components in process automation systems.
This protocol facilitates communications between various types of data acquisition and control
equipment and plays a crucial role in SCADA systems.
Describe the Inter-Control Center Protocol (ICCP) for data exchange between control centers.
Standards
COMTRADE
IEC 61850
IEC 61968, 61970
IEC CIM GID
Interface Services
(GDA, HSDA,
TSDA, GSE)
IEC Common
Information
Model
IEEE 37.118
NRECA
Multispeak
Web Services
Standards (SOAP,
WSDL, WS-*
specification)
XML
ZigBee Smart
Energy Profile
Common Format for Transient Data Exchange. It is intended for use by digital-computer-based devices
which generate or collect transient data from electric power systems. This standard facilitates
exchange of the transient data for the purpose of simulation, testing, validation, or archival storage.
For designing electrical substation automation.
Describe the business functions, business sub-functions and abstract components for distribution
management and set of applications for energy management system.
Four services associated with IEC CIM for data interchange in four classes: generic data, high speed
data, time series, and events
Primary schema for data representation; should also be applied to analytics outputs, which in
themselves are treated as data for purposes of transport, persistence, and interface to various
consuming systems.
Define Phasor Measurement data
Defines what data need to be exchanged between software applications in order to support the
business processes commonly applied at utilities. This leverages definitions of common data semantics,
definitions of message structure and definition of which messages are required to support specific
business process steps.
For defining interfaces and standards for interoperable system integration and service oriented
architecture.
For message oriented integration.

It enables wireless communication and control between utility companies and common household
devices such as smart thermostats and appliances.
Table 3 - Application Technology Recommendations
Application Technology
Application/transaction
processing server
Business Process Engine
Business process
integrator
Business rules engine
Connector framework
Enterprise Service Bus
(ESB)
A middleware software component dedicated to efficient execution of programs supporting

application construction.
Implements Business Process Execution Language (WS-BPEL) for process choreography.
Automates and optimizes business processes, within the organization and across the customers,
partners, and supply chains.
Software executing one or more business rules in a runtime production environment.
Allows data access from diverse sources.
Software providing complex architectures with fundamental services via an event-driven and
standards-based messaging engine. Foundational capabilities include invocation, routing,
mediation, protocol transformation, process choreography, service orchestration, complex
event processing, and QOS measures (reliable delivery, transaction management, & security)
Handles messaging resulting from pre-defined circumstances occurring across the enterprise.
Allows data contained in one database to be accessed through another.
Provides techniques for distributing workload evenly across two or more servers.
An integrated suite of components for an easy-to-use entry point to all enterprise business info
Allows independent and potentially non-concurrent applications on a distributed system to
communicate with each other.
SOA control and management tools (service interface management & discovery, monitoring)
Integrates and presents information from diverse sources in a unified way.
Delivers content (web pages) using the Hypertext Transfer Protocol (HTTP), over the web
Event processing
Integration middleware
Load balancers
Message gateway
Message queue
SOA governance tool
Web portal
Web servers
Analytics Services
Smart grid analytics generally reside within the cross domain foundational services box in the lower
right area of Figure 9 - Layered Services Tier View. Analytics provide the services needed to make
sense out of the data being created by smart grid sensors (smart meters, grid components, energy
management devices, etc.). Analytic tools are designed to turn large amounts of structured and
unstructured data into information useful to humans (consumers, utility operators, regulators) and
smart grid control mechanisms (demand response, outage management, advanced load controls).
Analytics Logical Model

The Analytics Logical Model [Figure 12] consists of three views: (1) analytics synergy, (2) analytics
services stack, and (3) analytics component.
Figure 12 - Analytics Logical Model
The synergy model illustrates a key concept of Smart Grid architecture: the manner in which data
sources from the grid produce data which, when processed in multiple ways through multiple
analytics, can support multiple business outcomes. Therefore, data sources (sensors) and analytics
processing tools and components can and should be shared over multiple capabilities. By arranging the
architecture to take advantage of the synergy, the Smart Grid architect can minimize infrastructure cost
while maximizing realized business value of the sensing and analytics elements of the Smart Grid.
While the synergy model is complex and can be difficult to understand, it has the potential for high
payback. In this synergy model diagram, data sources are arrayed at the bottom. Data from these
sources falls into one or more of four data classes as shown in the second tier. In the third tier, six
classes of analytics (process data from the data sources according to data class. In the top tier, analytics
support one or more utility business processes. Line coloring does not have a special meaning except to
make line groupings somewhat easier to follow on a crowded diagram. Finally, because visualization is
pervasive, it is shown as a blue box in the synergy model third tier, essentially underlying all of the
analytics classes, signifying their use in GUI-based decision support.
Analytics Structural Model

The analytics services structural model [Figure 13] is provided to help the smart grid architect consider
how to best deploy the various analytics services using a stylized representation of a typical utility
network infrastructure. At the top of the model are elements needed to support external agencies
(regulators, interchange and balancing authorities, etc.). At the bottom are the analytics services needed
by premise devices (smart appliances, PEV chargers, building energy managers, etc.). In between are a
dozen other tiers where analytics services may be located to support residing devices and functionality.
A self-describing template used for this model is on the last page of Appendix B, Services Classes
Concepts. Included are descriptions of all fourteen tiers used in the model.
Figure 13 - Analytics Structural Model
The Analytics Structural Model illustrates how analytics functionality can be distributed across a Smart
Grid. This is important to the smart grid architect because a distributed architecture can address issues
of latency, scale, and robustness. There are many places on the grid where analytics elements may
reside, and a key aspect of smart grid architecture is to develop a proper combination of distributed
and centralized analytics elements. There are significant tradeoffs between the degree to which
analytics are distributed and the resulting requirements for communications services, as well as data
services. Furthermore, the distribution of analytics must be coordinated with the control architecture,
since some analytics are consumed by controls systems which are also distributed and require the
analytics as inputs on a low-latency basis.
Analytics Architecture Specifications

Table 4 is a list of general analytics specifications. The justification for each is provided to enhance the
readers understanding of each specification.
The table does not include detailed business or technical requirements a specific analytics tool would
fulfill. Each utility must include requirements for analytics services in every relevant smart grid project.
Table 4 - Typical Analytics Specifications
Specification
Analytics shall be dynamically re-distributable a service to
manage the re-distribution must be included in the analytics
architecture.
Analytics services shall be centrally and uniformly managed. The
management mechanism should be integrated with the general
network and grid device management services.
Analytics services shall be deployable in a distributed fashion.

Places on the grid for analytics deployment include:
Data centers
Control centers
Substations
Mobile devices
Edge devices, including meters, gateways

Communications devices
Cloud services (private and third party)
Distribution feeder power system devices
Analytics shall be distributed according to a latency hierarchy.

Some analytics will be implemented close to data sources and
consumers, while others can be implemented at control centers
or data centers. Analytics associated with protection and control
should be distributed; analytics for asset health and stress
accumulation can be centralized. Analytics for grid state should be
distributed. Analytics for consumer behavior can be centralized.
Smart grid analytics services architecture shall include analytics
tool management. Such tools include those that enable the
development and deployment of rules for event processing
engines, configuration tools for computational analytics, and
workbenches for tools highly interactive in nature.
Data quality monitoring for low latency analytics shall be
incorporated into the analytics service at the point of deployment
for immediate detection of data channel failures.
The control systems architecture shall be developed as a
Justification
Analytics change as the Smart Grid evolves and it is
impractical to physically visit distributed analytics
elements to make changes.
It is impractical to use a distributed architecture that
requires field frequent visits to devices, in fact, Zero
Touch deployment is necessary for Smart Grids at
scale. Integration with the management services
architecture for distributed architecture operations to
be feasible.
Wherever data is generated or information consumed
is a location candidate for appropriate analytics.
Communication network elements hosting additional
software are also good candidates, since generally
these elements are where data sources and consumers
reside. Use of these to host analytics makes it possible
to provide the benefits of distributed architecture
while minimizing the number of devices to be managed
and maintained. Zero-touch deployment is crucial.
The tradeoff between degree of distributed
intelligence and communications requirements is one
of the most significant decisions smart grid architects
must make. This tradeoff must be made early in the
design process and revisited periodically as the grid
transformation proceeds.
As the utility transforms its grid, forms and uses of
analytics will change. In addition, new analytics are
being developed as grid data becomes available. The
utility must not expect analytics deployment to remain
static. Thus, having access to the appropriate tools to
manage the analytics transformation is crucial.
Many data acquisition devices suffer data channel
failures with the device not generating a fault alarm.
Since the data may be used in a real-time mode, it is
necessary to have ways to detect faulty data in realtime. This must be done at or near the source since
much of this data will never reside in a database. In
addition, real-time control may depend on the
correctness of this data and the consequent analytics.
Since controls consume analytics widely, the control
precursor to the analytics services architecture development.

Comprehensive data access strategy, grid observability strategy
and sensor architecture shall be developed to support the
development of the analytics services architecture.
Distributed analytics in hierarchical analytics services architecture
shall be designed to reduce data volumes for data moving from
edge devices up through successive layers of data management
and analytics to the points of data persistence. This is one of the
points of intersection between analytics services architecture and
communications services and data services architectures. Note
that this type of volume reduction does not apply to usage
(meter) data. Aggregation of non-usage analytics should generally
be homologous with the disaggregation of control signals (see
Control section).
Distributed analytics shall provide logging capabilities for
evaluating analytics operation. This includes event processing, and
the management of analytics logs is a significant data services
architecture issue.
Multiple deployment models to implement analytics shall be used
for distributed analytics including standalone, hierarchical, and
peer models. Event analytics may be broken into event stream
processing at endpoints, feeding higher level complex event
processing at substations, control centers, and data centers.
For low latency analytics, implementations shall be located at or
very near the source(s) of data and the primary outputs
destination(s), without sending data to and from remote
processing centers. Embedded processing shall be used, but the
actual analytics must be downloadable.
Information-sharing among distributed analytics is often
necessary; Smart Grid analytics services architecture shall include
a real-time distributed data sharing mechanism. This is essential
for access to a global grid state, which is needed not only by
analytics, but also by control and other applications.
Interface of distributed analytics services at the system level
requires that analytics be treated in two ways: as data bound for
data persistence (data stores) and as streams (synchronous or
asynchronous) bound for consumption by applications in realtime. In some cases, the analytics outputs will be treated both
ways simultaneously, leading to implications for data and
communications services architecture.
As-operated grid connectivity shall be made available to analytics
requiring grid context (grid state), each analytic sensitive to grid
topology must have the correct grid state time-aligned with the
formation of the data or event upon which the analytic depends.
Security shall be part of analytics services design. This includes:

Permissions for source and target data sources
Permissions to execute on centralized and distributed locations
systems architecture is a vital analytics design input.

Provides inputs vital to the development of the
analytics architecture, due to the infrastructure
optimization problem discussed in the section for the
analytics structural model.
The point is that analytics extract key information,
generally resulting in a data volume reduction while
maintaining essential information. In some cases, raw
data may be retained and persisted for later analysis
based on application-specific trigger conditions, but
generally lower latency analytics will consume raw data
and pass along information to either consuming
applications, or higher level analytics. This may not be
feasible in non-hierarchical analytics services
architectures (tier-based data volume management).
Event logging is necessary to support post mortem
analyses of various kinds. With the volume of events
that can be generated in a Smart Grid, management of
the event logs is a large issue.
It is important to recognize that distributed analytics
elements do not have to be functionally complete in
themselves; it is often more useful for elements to
compute partial results and the either forward them
upward into a hierarchy or exchange partial results
with other distributed elements.
This is a direct consequence of the distributed nature
of power grids and their control systems.
Electrical effects propagate across the grid at very high

speeds and with wide reach. Effects at the distribution
level can affect transmission and vice versa. Grid state
and other data may be needed almost anywhere to
support analytics and control.
Some analytics operate on telemetry, but are not used
for real-time operations. They may be monitored by
agents or simply archived for batch processing to
support various business processes. Consequently,
there are both communications and data services
implications that must be coordinated by the smart
grid architect.
This problem is fundamental due to the frequent
topology changes to distribution grids. It is also an
issue for wide area measurement systems. For many
processes it is possible for the grid topology to change
before a prior event or datum is processed, so past
values of grid topology must remain available.
This set of security and management features must be
integrated with the overall security and management
architectures. For implementations of distributed
Permissions for analytics to communication to other analytics

Permissions for users to access the dashboards or KPI
Permissions on who can modify/start/stop/deploy analytics
Tools for tracking changes in the actual analytical algorithms
Visualizations are analytics for the eye/brain; therefore,
visualization shall be a part of analytics services architecture.
analytics such as multi-agent systems and others

providing downloadable, zero-touch capability, it is
crucial that the downloadable elements be verifiably
legitimate via certificates, etc.
The smart grid architect should treat visualization as an
integral part of the analytics architecture. Visualization
is needed at many grid levels and locations; treating it
as a separate centralized function can lead to difficulty
in uniformly providing the service.
Architecture Standards and Technology Recommendations

Technologies will evolve as a utilitys Smart Grid transformation takes place over a period of many
years. Changes in analytics services technologies are inevitable. As of this writing, a number of
technologies and standards are appropriate for implementing analytics services. Table 5 lists these
standards with their purpose or relevance; Table 6 similarly lists the in-place or emerging technologies.
Table 5 - Recommended Analytics Standards
Standards
IEC 61850 GOOSE messaging
IEC CIM GID Interface Services

(GDA, HSDA, TSDA, GSE)
IEC Common Information Model
IEEE Computer Society FIPA

(Foundation for Intelligent Physical Agents)
For use in low latency protection and control messaging, where analytics
outputs are being used in applications such as adaptive protection and real
time grid stabilization
Four services associated with IEC CIM for data interchange in four classes:
generic data, high speed data, time series, and events
Primary schema for data representation; should also be applied to analytics
outputs, which in themselves are treated as data for purposes of transport,
persistence, and interface to various consuming systems.
For analytics implementations using multi-agent systems
Table 6 - Recommended Analytics Technology
Analytics Technology
Data mining
Digital signal processing
Event stream/complex
event processing
OLAP/Cubing/Dashboard
s
Phasor/power system
calculation processing
Statistical analyses
Visualization
Needed to analyze vast volumes of grid data to detect and extract underlying patterns and
models
Needed to extract information from low level grid data such as waveforms and sensor telemetry
Needed to filter, throttle, correlate, and extract situational understanding from multiple
asynchronous event streams from up to millions of grid devices; management of event stream
bursts.
These are visualization tools for data trending and status indication. Such tools should be
connected via appropriate security services to data and analytics output feeds from the control
center, as well as data residing in enterprise databases.
Necessary to support a wide range of real time analytics involving grid state, device utilization,
power flow and load control, and fault analysis
a variety of statistical analysis tools may be applied to problems such as demand and variable
energy resources modeling, as well as customer behavior modeling.
Crucial to translate both data and numerical analytics into forms readily comprehended by
humans for decision support; typically coupled with geospatial and grid topology information
for context; also includes graphics for trending and forecasting on sensor telemetry
Data Services
Smart grid data services generally reside within the cross domain foundational services box in the
lower right area of Figure 9 - Layered Services Tier View (labeled Data Management Services).
Data Services Logical Model

The Data Services Logical Model [Figure 14] consists of three views: (1) data services synergy, (2) data
services stack, and (3) data management component.
Data Services Synergy Model
Consumers/
Processes
Analytics
System Mgmt
Data
Data Management Services
Data Discovery
Data Indexing and

Reference
Unstructured
Content
Enterprise Application
Data Registration and Life

Cycle Management
Data Services Stack Model

Foundation
B2B
Data Access & Update
Visualization
Consumer Service
Manually entered information

(inspections, readings, etc.)
Network state estimation
Market operations signals
Core
Content Management
Master Data Management
Data Flow Orchestration
Data Manipulation
Data Collection
Geospatial information
Reporting
Electrical Network model
Data Transformation
Data Quality and Integrity
Data Storage
Data Classes
Time Series Data
Event Data
Market operations model
Measurement model
Asset catalogue
CIM/61850 interface
Compatible units
Customer information
Asset data
Premises information
Edge device model
Integration
Data Security
Operational Data
Network measurements
Analysis
Records
Meta Data
messaging
data access
transformation
data synchronization
encryption
master data management
Support Services
Sources
SCADA
MDM
Protection
Equipment
Customer
Interface
Third
Parties
External
Data Feeds
Field
crews
IVR/Call
Center
Enterprise
Application
governance
access control services
transport
semantic model management
storage
message & service definition
Data Management Component Model
Meta Data
Management
Semantic Model
Management
ETL
ESB
EII
Persistent Data
Storage
Archive
Figure 14 Data Services Logical Model
The synergy model (upper left area of Figure 14) shows how Smart Grid ICT must simultaneously
manage data from many sources to support multiple business outcomes. Data must therefore be
decoupled from data sources to allow sharing of both the data and the components used for moving,
manipulating and storing it. By arranging the architecture to leverage this synergy, the Smart Grid
architect can minimize infrastructure cost while maximizing the realized business value of enterprise
Smart Grid information management. The Synergy Model has the primary data sources arrayed at the
bottom. Data from these sources fall into one or more of the five data classes depicted in the second
tier. In the third tier, key data management services of the Utility Services Layer and the Core Business
Services Layer process data from the data sources according to data class. In the top tier, various
business processes and consumers leverage the data management services to accomplish higher level
business functions. Line coloring does not have a special meaning except to make line groupings easier
to follow on the crowded diagram. Pervasive security is represented as a blue box in the models third
tier, underlying all data management services.
In the data service stack model (upper right area of Figure 14), the core grouping is an abstraction of
capability services types (refer to the discussion of services in Appendix B). These services focus on
business capabilities and are intended to be independent of any particular business process. The stack
model also contains services from the process service and solution service layers used to accomplish
higher level services within the foundation grouping. These foundational services, as well as lower
service layers, are used by the consumers/processes tier of the synergy model to accomplish needed
business functionality.
Data Services Structural Model

The data services structural model [Figure 15] illustrates how data services can be distributed across a
smart grid. This is important to the smart grid architect because distributed data architecture can
address issues of data access, storage, transformation, latency, encryption, and synchronization within
and across layers in the physical grid. While traditionally these services have been concentrated in data
and control centers, in a smart grid these distributed data services will reside in substations, field
devices, and in various network locations from the end use premises to the control center. A selfdescribing template used for this model is on the last page of Appendix B, Services Classes Concepts.
Included are descriptions of all fourteen tiers used in the model.
Figure 15 - Data Services Structural Model
Data Architecture Specifications

Table 7 is a list of general data specifications. The justification for each is provided to enhance the
Table 7 - Typical Data Services Specifications
Specification
Justification
A semantic model shall be built to create and

maintain common business definitions,
business rules (requirements), and metadata.
Data classification shall be performed.
The creation of common business definitions will facilitate

communications in all directions within the organization. This should be
accomplished as an integral part of incrementally building the enterprise
semantic model.
Classify data for security and management purposes.
Specification
Justification
Data Enrichment shall be provided where

necessary.
Data integration shall be provided.
Data movement shall be provided.
Data quality and integrity shall be source
guaranteed.
Appropriate security shall be applied to data.
Data shall not be tied to applications
Appropriate access shall be provided to data
sources
Data synchronization shall be supported
where necessary.
Data transformation shall be provided where
necessary.
Data shall be validated as appropriate.
Data Object Indexing and referencing shall be
provided.
Data growth shall be managed.
Master data management shall be provided.

Methods shall be provided for understanding
and removing data duplication
Enrich the data by supplementing it with other sources as needed and per
the understood the business process that is implemented
Integration data for process automation and business transactions.
Enable data to move from one source to another.
Ensure that the data is guaranteed by the source to be of primary source
quality and not derived or distorted by secondary views.
Provide security for data in accordance with its classifications. Security
activities include authentication and authorization, logging, and control.
Data should be made available as master data. A single view of data
should exist across the enterprise shared, complete, and accurate.
Provide access to data sources, either through application or directly,
while maintaining appropriate security.
Synchronize data instance and content for multiple systems of same data.
Transform data from one semantic and syntax to another.
Validate data in accordance with defined business rules.
Centralize a robust means of translating data object identifications
between disparate systems.
Adhering to EIM practices will avoid having the same data expressed in
multiple ways, each with the same or similar meaning. Data growth is also
managed by understanding what data must be retained for what periods
of time and within which physical data stores and systems.
Ensure consistent master information across transactional and analytical
systems.
Have repeatable rules definition for guaranteeing data quality.
Data Architecture Standards and Technology Recommendations

The following table of data standards and technology recommendations is provided to the smart grid
architect for reference. Over time, however, innovations will inevitably diminish its completeness. The
architect should always research the latest information on these topics, but this table is a good starting
point. Table 8 lists important 2011 standards and technology recommendations applicable to data
services, each with a brief explanation of their purpose or relevance.
Table 8 - Data Standards and Technology Recommendations
Standards
Applicable functional
standards of the IEC
61968 and 61970 series
of standards
IEC 61850
IEC 61968-11
Industry standard message payloads are defined using XSD and RDF. Canonical Data Models
(CDMs) of a utility may be compliant with, or based of (if extensions are required) these industry
standard message payloads.
Object oriented protocol for retrieving data and controlling devices at substations and along
feeder networks.
System Interfaces For Distribution Management Part 1 Interface Architecture and General
Requirements
Standards
IEC 61968-11 and IEC
61970-301
MultiSpeak
OASIS UDDI
Specification
Simple Object Access
Protocol (SOAP)
W3C XML Specification

WSDL
WS-I Basic Profile
IEC Common Information Model. Information model for data representation which is used as a
basis for defining industry standard application interfaces.
The MultiSpeak project is funded by National Rural Electric Cooperative Association (NRECA). It
defines standardized interfaces among software applications commonly used by electric utilities.
It defines details of data that need to be exchanged between software applications in order to
support different processes commonly applied at utilities.
Universal Description, Discovery and Integration (UDDI) is a platform-independent, Extensible
Markup Language (XML)-based registry is a mechanism to register and locate web service
applications.
SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for
exchanging structured information in the implementation of Web Services in computer networks.
It relies on Extensible Markup Language (XML) for its message format, and usually relies on other
Application Layer protocols, most notably Remote Procedure Call (RPC) and Hypertext Transfer
Protocol (HTTP), for message negotiation and transmission. SOAP can form the foundation layer
of a web services protocol stack, providing a basic messaging framework upon which web services
can be built. This XML based protocol consists of three parts: an envelope, which defines what is
in the message and how to process it, a set of encoding rules for expressing instances of
application-defined data types, and a convention for representing procedure calls and responses.
Extensible Markup Language (XML) is a set of rules for encoding documents in ... in the XML 1.0
Specification produced by the W3C.
WSDL is an XML-based language for describing Web services and how to access them.
The WS-I Basic Profile (official abbreviation is BP), a specification from the Web Services
Interoperability industry consortium (WS-I), provides interoperability guidance for core Web
Services specifications such as SOAP, WSDL, and UDDI. The profile uses WSDL to enable the
description of services as sets of endpoints operating on messages.
Control Services
Smart grid control services generally reside within the cross domain foundational services box in the
lower right area of Figure 9 - Layered Services Tier View.
Control Services Logical Model

The Control Services Logical Model [Figure 16] has three views: control synergy, control services stack,
and control component.
Figure 16 - Control Services Logical Model
The synergy model diagram (upper left area of Figure 16) is the most complex, containing four tiers.
The bottom two tiers match the analytics synergy model described previously. The third tier consists of
key smart grid control services. The top tier shows control-oriented business processes. At the bottom
of the second tier, connectors illustrate how various grid devices create data for use in control. Line
color is only for the purpose of visual clarification the colors do not signify any special property or
characteristic. The synergy model diagram highlights several crucial issues for the smart grid architect
to analyze:
Need for grid state aggregation and publication.
Use of multi-controller, multi-objective control inherent in smart grid design using grid data
sources to support multiple business processes via processing of multiple analytics.
Federation of control systems as a consequence of multi-controller, multi-objective control.
Disaggregation of control command at the device level. This must take into account the
actual grid topology at the time of control actuation, as well as various grid state variables.
These significantly impact the design of controls, communications, sensor, and analytics architectures.
Control Services Structural Model

The control services structural model [Figure 17] is provided to help the smart grid architect consider
how to best deploy the various control services using a stylized representation of a typical utility
(regulators, interchange and balancing authorities, etc.). At the bottom are the control services needed
by premise devices (smart appliances, PEV chargers, building energy managers, etc.). In between are a
dozen other tiers where control services may be located to support residing devices and functionality.
A self-describing template used for this model is on the last page of Appendix B, Services Classes
Concepts. Included are descriptions of all fourteen tiers used in the model.
Figure 17 - Control Services Structural Model
Control Architecture Specifications

Table 9 is a list of general control specifications. The justification for each is provided to enhance the
Table 9 - Typical Control Specifications
Specification
Control signals must be disaggregated in a hierarchical manner
in parallel to both the general structure of the power grid and
the aggregation of analytics and grid state (see Analytics
section).
Control system architecture must provide means to control

systems not part of the grid itself.
Control system must integrate adaptive protection at both

transmission and distribution levels.
Control systems for demand response and DER control must

provide for dispatch from the balancing authority; control
signals must be disaggregated to the distribution substation
level, and from there to the feeder device and premises level.
IVVC must be coordinated with DR at the distribution feeder
level, so the control architecture must provide for control
disaggregation and recalculation at multiple levels in the grid.
Control systems must have access to grid state determined by
both wide area measurement as well as deep measurement;
deep measurement means grid state at the distribution and
premises levels must be part of extended grid state; the control
system architecture must provide for wide distribution of grid
state across control elements.
Control systems must support both event-driven functions and
closed loop servo functions. Close loop servo control
architecture must accommodate multiple time scale operation,
so control architectures must provide means for complex
feedback and feed forward.
For grids where stabilization or compensation is required at the
distribution level, the control system shall be capable of
operating with a complete closed loop path execution in less
than two power cycles.
Grid state determination for wide area measurement and wide
area control shall depend to the maximum degree possible on
actual measurement, with the minimum estimation necessary
to complete the grid state view. Control system architecture
must distribute grid state across control systems elements in
real time in a secure manner.
Justification
All grid systems are interconnected through the analog
power grid with many interactions. To provide the means
to reconcile control commands and eliminate
undesirable interactions, the grid structure must guide
control signal disaggregation. Control system
architecture not providing for disaggregation at the
various levels of the grid hierarchy will limit the ability of
control system designers to solve interaction problems.
Secondary load control for Demand Response and
integration of DER, microgrids, and PEV charging
stations/networks requires utility interface due to
interactions resulting in grid management issues.
The increasing penetration of secondary load control
systems causes interactions, including non-outage cold
load pickups requiring dynamic modification of
protection settings based on both grid state and control
actions.
Without the proper disaggregation, interaction between
DR and IVVC can cause grid violations, and can cause DR
to be significantly less effective than expected. Other
interactions of grid controls and secondary load controls
can occur, up to and including wide area blackout.
Extended grid state is the essence of deep situational

awareness and is the primary set of observations driving
control systems. As multiple control sub-systems share
common elements, ubiquitous access to grid state
becomes crucial.
Some control functions can be event based, but other
highly dynamic processes such as stabilization require
continual closed loop control update. With multi-time
scale systems, control loops must be more complex than
simple feedback, so control architecture must support
multi-feedback, multi-time scale operation.
Dynamics of close loop stabilization require much faster
response and much lower latencies than traditional
distribution automation. New control devices are
capable of acting at these speeds (see Control
Technology table below).
Advanced grid controls need access to actual grid state;,
especially at the distribution level where estimation is
effectively impossible. In addition, extended grid state
contains elements not susceptible to estimation, such as
quality state.
Specification
Justification
Multiple control systems must be federated before control

signals are sent to individual devices. The control service
environment shall be a multi-controller, multi-objective
environment.
Power grid control must be a hybrid of centralized and

distributed control elements, with distributed control extending
into substations and to distribution grid elements; control
elements shall be able to use peer-to-peer communication to
cooperate on control tasks and shall be capable of autonomous
operation when communication with higher level controls is not
possible.
Smart grid control systems can require cross tier integration;
this may be accomplished in a hierarchical fashion normally or
via tier-jumping where very low latency is required. Control
system architecture must allow for cross-tier control solutions.
System models (connectivity models) for transmission,
substations, and distribution are context for control - control
systems must have a means to receive the relevant portions of
connectivity models from the master sources in a secure and
timely manner. Timeliness is dependent on the rate at which
connectivity changes can occur relative to the essential time
constants of the relevant control subsystems.
Teleprotection must be done via packet switching (Ethernetbased) networks rather than circuit switching networks
As smart grid functionality increases in sophistication,

more control processes have reasons to access the same
control elements in the grid. Such sharing is important
for economic reasons but the controls must not collide at
the control elements; hence the need for federation in
the architecture to provide resolution mechanisms.
Centralized control is not adequate for fully built out
smart grids; using a combination of centralize and
distributed control elements provides scalability and
robustness while maintaining central supervision and
management of the grid.
Smart grid controls are increasingly required to deal with

effects propagating through the grid, including from
distribution to transmission. In addition, some business
models allow for secondary control systems external to
the utility control system and operating across tiers.
System models are context for both analytics and
control; without this context proper control action
cannot be determined.
Tele-protection in a smart grid environment needs

flexibility not available via circuit switching
Control Architecture Standards and Technology Recommendations

The following table of control standards and technology recommendations is provided to the smart
grid architect for reference. Over time, however, innovations will inevitably diminish its completeness.
The architect should always research the latest information on these topics, but this table is a good
starting point. Table 10 lists important 2011 standards and technology recommendations applicable to
control services, each with a brief explanation of their purpose or relevance.
Table 10 - Recommended Control Standards and Technology
Standards
DNP3
IEC 60870-5-101,104
IEC 61850 GOOSE messaging
IEC 61850-90-5
IEC CIM GID Interface Services
(GDA, HSDA, TSDA, GSE)
Commonly used for communication with grid control devices. May be
operated in native serial fashion, or over IP.
Serial communication for control devices.
For use in low latency protection and control messaging
Draft standard for PMU communications support for multi-cast
Four services associated with IEC CIM for data interchange in four classes:
generic data, high speed data, time series, and events
Standards
IEC Common Information Model
IEEE C37.118
IEEE Computer Society FIPA
(Foundation for Intelligent Physical Agents)
Primary schema for data representation; should also be applied to

analytics outputs, which in themselves are treated as data for purposes of
transport, persistence, and interface to various consuming systems.
PMU communications
For control implementations using multi-agent systems
Most grid control devices and control systems are well known. The section below discusses some
advanced control elements and technologies.
Table 11- Advanced Control Elements and Technologies
Control Technology
Distribution level PMU

networks
DSTATCOM
Can provide distribution grid state, fault intelligence, asset utilization measurement and outage
intelligence inputs for the relevant control sub-systems.
Distribution STATCOM provides electronic stabilization and dynamic power quality compensation
at the distribution level.
Software technology for implementation of distributed intelligence; can be used to implement
distributed control agents.
Increasingly important for electronic stabilization as grid rotational inertia is decreased through
the displacement of traditional generation with VER. Includes such applications as model power
oscillation damping and frequency compensation.
When used as grid interfaces from DG and microgrids, and when controlled by the utility, these
can provide fast VAR compensation (much faster than capacitors) and can provide much finer
granularity in VAR control.
Provide necessary state measurement for transmission control.
Multi-agent systems
STATCOM / SVC /
FACTS / fast ancillary
storage
VAR-controllable ACDC inverters
WAMS/PMU networks
Security Services
Smart grid security services generally reside within the cross domain foundational services box in the
lower right area of Figure 9 - Layered Services Tier View.
Security Logical Model

The Security Logical Model [Figure 18] has three views: the security component, the security services
stack, and security synergy.
Figure 18 - Security Logical Model
The Security Component Model depicts in block format the primary security components used.
The Security Services Stack Model has several parts:
Support services services that may come from another portion or tier of the architecture but
are necessary to support the services in the tier being described
Foundation services key security services, generally needed throughout the architecture which
other services depend or expand upon
Core services the primary security architecture service stack
Integration services services specifically providing integration between security and other
architectural tiers or business systems
The Security Synergy Model illustrates how security services can be shared to meet various Smart Grid
security requirements. If the architecture can take advantage of this synergy, the utility can build cost
effective security infrastructure services, reused across multiple Smart Grid systems.
Security Structural Model

The security structural model [Figure 19] is provided to help the smart grid architect consider how to
best deploy the various security services using a stylized representation of a typical utility network
infrastructure. At the top of the model are elements needed to support external agencies (regulators,
interchange and balancing authorities, etc.). At the bottom are the security services needed by premise
devices (smart appliances, PEV chargers, building energy managers, etc.). In between are a dozen other
tiers where security services may be located to support residing devices and functionality. A selfdescribing template used for this model is on the last page of Appendix B, Services Classes Concepts.
Included are descriptions of all fourteen tiers used in the model.
Figure 19 - Security Structural Model
The structural model illustrates how security functionality may be distributed across a Smart Grid. The
Smart Grid architect needs to work closely with security experts to ensure appropriate security
principles are applied at every level of the Smart Grid structure. As the grid evolves, millions of new
components will be introduced; each is expected to ensure power systems operations maintain cyber
confidentiality, integrity, and availability. The NIST Interagency Report 7628 (NISTIR 7628), Guidelines
for Smart Grid Cyber Security: Vol. 1 (NIST-ITL, 2010) provides a Smart Grid Logical Reference Model
with dozens of logical interfaces identified. Chapter 2 and Appendix G of NISTIR 7628 should be
studied to ensure appropriate security attributes are addressed for each logical interface category.
NISTIR 7628 is freely available on the NIST Smart Grid website: www.nist.gov/smartgrid
Security Architecture Specifications

NISTIR 7628, Chapter 3, has an extensive listing of high level Smart Grid security requirements.
Security Standards and Technology Recommendations

The following table of security standards and technology recommendations is provided to the smart
grid architect for reference. Over time, however, innovations will inevitably diminish its completeness.
The architect should always research the latest information on these topics, but this table is a good
starting point. Table 12 lists important 2011 standards and technology recommendations applicable to
security, each with a brief explanation of their purpose or relevance.
Table 12 - Security Standards and Technology Recommendations
Standards
Purpose, Relevance or Comments
Digital Signature (DSS, DSA, RSA, etc.)

DNP3 Secure Authentication
Encryption (AES, RSA, etc.)
Hash (SHA-1, SHA-256, HMAC, etc.)
IEC 62351 Utility Communication Security
IEEE 1686 IED Security
IEEE 1711 Trial Use Standard for a SCADA Serial
Link Cryptographic Modules and Protocol
IPSec
NERC Critical Infrastructure Protection (CIP)
Standards
Public Key Infrastructure (X.509)
PubsFIPS
TLS
Wireless Security (WEP, WPA, etc.)
Cryptography and network security

User & device authentication, data integrity protection
Facilitates secure (secret) communication
Cryptographic hash functions employed in several widely used security
applications
Developed to handle the security of IEC Technical Committee 57
protocols (IEC 61850, 61968, etc.)
Minimum requirement set for intelligence electronic device security
compliance with NERC CIP requirements
Cyber Security of substation serial links
Internet Protocol Security secures IP communications by authenticating
and encrypting each sessions IP packets
The NERC Critical Infrastructure Protection program aims to improve
physical and cyber security for the bulk power system of North America
as it relates to reliability.
A cryptographic ITU-T standard for a public key infrastructure (PKI) for
single sign-on (SSO) and Privilege Management Infrastructure (PMI)
Federal Information Processing Standards (FIPS) Publications - a series
of documents for the U.S. Federal government issued by NIST
Transport Layer Security, a network protocol and successor to Secure
Sockets Layer (SSL)
IEEE 802.1X encryption standards designed to prevent unauthorized
access or damage to computers using wireless networks
Communications Services
Smart grid communications services generally reside within the cross domain foundational services
box in the lower right area of Figure 9 - Layered Services Tier View.
Communications Services Logical Model

The Communications Services Logical Model [Figure 20] has three views: the communications services
component, communications services stack, and communications services synergy.
Figure 20 Communications Services Logical Model
The Communications Services Component Model depicts in block format the primary communications
components used in the architecture.
The Communications Services Stack Model has several parts:
Support services services that may come from another portion or tier of the architecture but
are necessary to support the services in the tier being described
Foundation services key security services, generally needed throughout the architecture which
other services depend or expand upon
Core services the primary communications architecture service stack
Integration services services specifically providing integration between communications and
other architectural tiers or business systems
The Communications Synergy Model illustrates how communications services can be shared to meet
various Smart Grid communications requirements. If the architecture can take advantage of this
synergy, the utility can build a cost effective communications infrastructure services, reused across
multiple Smart Grid systems.
Communications Services Structural Model

The communications services structural model [Figure 21] is provided to help the smart grid architect
consider how to best deploy the various communications services using a stylized representation of a
typical utility network infrastructure. At the top of the model are elements needed to support external
agencies (regulators, interchange and balancing authorities, etc.). At the bottom are the
communications services needed by premise devices (smart appliances, PEV chargers, building energy
managers, etc.). In between are a dozen other tiers where communications services may be located to
support residing devices and functionality. A self-describing template used for this model is on the last
page of Appendix B, Services Classes Concepts. Included are descriptions of all fourteen tiers used in the
model.
Figure 21 - Communications Services Structural Model
Communications Architecture Specifications

Table 13 is a list of general control specifications. The justification for each is provided to enhance the
Table 13 - Typical Communications Specifications
Specification
Architecture for end-to-end communications shall be divided into functional
subnetworks including the following:
Extranet
Data/Control Center Networks
Two Tier Wide Area Network
Core Network
Backhaul Network
Substation Network
Two Tier Field Area Network
Tier 1 Multipurpose FAN
Tier 2 Purpose-Built FAN
Premises Network
Backhaul Wide-Area Networks Deployment
Design specs shall:
Accommodate tightly controlled access from remote networks
Provide a high degree of security
Provide high network performance primarily using fiber, microwave and
other infrastructures
Provide flexible network segmentation/virtualization capabilities, in support
of a variety of application, security, and geographical domains
Support data, voice, video, and control services
Be based on IPv6 technologies
Support convergence such that, if desired, traffic from one does not harm or
adversely impact traffic from other environments
Justification
Each of the sub-network domains
has unique functional
characteristics regardless of
communications technology
considered.
Provides high performance and

resilient connectivity between
core wide-area networks and key
remote facilities (such as outlying
substations) or to points of
network concentration (such as
remote communications huts).
High performance attributes:
from hundreds of Megabits to
multi-Gigabit, extremely low
latency, deterministic traffic
support, very high reliability.
Operational specs should:

Support key remote locations where grid logic is employed
Be under autonomous control by utility (if private) or accompanied by strict
service-level agreements (if public)
Provide a high degree of network monitoring and system management
Communication architecture shall anticipate and support highly distributed data
collection, control, and analytics environments.
Data collection, control and

analytics are evolving from
centralized to distributed
environments and the
communication architecture must
support this evolution.
Communication networks shall be based on standardized packet transport

services and utilize IPv6 technology.
IPv6 offers superior networking

functionality and can scale to
meet the needs of Smart Grid.
Specification
Justification
Communication services must be centrally and uniformly managed. The

management mechanism should be integrated with grid device management.
Communication systems entail

many diverse, interconnected and
interdependent communication
links. These systems are also
interdependent with grid devices
and each management system
should inform the other for
service impacts.
Completion of a comprehensive set of anticipated use cases is a critical

foundation for the development of the communication services architecture
Provides comprehensive inputs

and requirements vital to the
development of the
communications architecture.
Prevents silo view that can lead
to duplicate infrastructure and
expenses.
Core Wide-Area Networks Deployment
Provides high performance and

resilient connectivity within the
same organizations data/control
centers, from data/control
centers to key remote facilities
(such as substations), and from
data/control centers to points of
backhaul network
interconnection
Design specs should:

Accommodate tightly controlled access from remote networks
Provide the highest degree of security
Provide high network performance (multi-Gigabit, extremely low latency,
deterministic traffic support, very high reliability, rapid failover, extensive
redundancy) primarily using fiber and other infrastructures
Provide flexible network segmentation/virtualization capabilities, in support
of a variety of application, security and geographical domains
Utilize diversely connected, redundant connectivity architectures (such as
ring or mesh topologies)
Support convergence such that, if desired, traffic from one environment
does not harm or adversely impact traffic from other environments
Operational specs should
Directly support key remote locations where grid logic has been employed
Be under autonomous control by utility (if private) or be accompanied by
strict Service Level Agreements (if public)
Provide a high degree of network monitoring and system management
Development of holistic end-to-end communication architecture is critical to
support entire application, control and analytics environments.
Application, control and analytics

endpoints span multiple domains
of the communications
architecture.
Specification
Extranet Network Deployment
Provide network security suitable for a plethora of access scenarios
Support access for thousands to millions of users (based on the number of
customers served by the utility)
Interconnect to several public infrastructures (carriers) and offer various
networking services (Internet, data, voice, video, control)
Provide performance and capacity commensurate to normal business needs
as well as sufficient additional capacity to accommodate emergency
situations
Include link and service failover mechanisms to alternative external
networks and/or service providers
Justification
Provides connectivity outside the
utility (to customers, suppliers,
business partners, emergency
services, the public at large, and
to off-site utility employees) with
appropriate access and isolation

Assume that extranet connectivity may not allow utility autonomous control
over service
Assume that extranet connectivity offers lesser degree of monitoring and
management to remote devices than private networking
Consider extranet connectivity is dependent on others for reliability and
performance
Consider extranet connectivity cost structure is largely capacity driven
Local Area Networks within Operations/Data Centers Deployment
Provide extremely tight access controls
Provide highest degree of network performance (multi-Gigabit, extremely
low latency, highest reliability, rapid failover, extensive redundancy) using
fiber and other infrastructures
Provide complete virtualization capabilities, including server, network,
storage, security, and application services
Minimize power consumption and provide redundant/backup power
For high-performance hosting of

centralized data collection,
control and analytics applications;
hosting storage systems and
enabling operator/worker access,

Serve as a key location for grid intelligence
Serve as termination facility for redundant extranet communications
Serve as termination facility for redundant internal core networks
Be under full autonomous control by utility or their designee
Provide the highest degree of monitoring and system management
Specification
Premises Networks Deployment
Design specs:
Provide controlled access to premises-located devices
Provide network performance commensurate with applications (from tens
to several hundred kilobits, application specific latency, sufficient reliability,
and redundancy where appropriate)
Support data and control services
Justification
To provide connectivity to
premises devices (such as inhome displays, programmable
communicating thermostats, etc)
and premises energy controllers
or a gateway,
Operational Specs should:

Aggregate and deliver traffic from premises devices to energy controllers,
displays, or gateways
Use unlicensed spectrum under control of premises owner/operator
Support self-discovery and auto-configuration of endpoint devices
Substation Local Area Network Deployment
Design Specs should:
Accommodate very tightly controlled access from intra-station devices or
from field area networks
Provide high network performance primarily using fiber and other high
performance infrastructures
Support virtualization capabilities internal to the station as well as to the
Backhaul WAN
Require segregated overlay solutions for separating process bus traffic from
other traffic
Be capable (if desired) of supporting diversely connected WAN uplinks
Support convergence such that, if desired, traffic from one environment
does not harm or adversely impact traffic from other environments
Provide autonomous support for low-level networking functions (such as
DHCP, distributed DNS, and gateway services)
To provide coverage to smart

devices within and nearby the
substation. High performance
attributes: several hundred
Megabit or even multi-Gigabit,
extremely low latency,
deterministic traffic support, very
high reliability rapid failover,
redundancy

Directly support devices and systems where grid logic is collected, executed,
and stored
Be under autonomous control by utility
Provide the highest degree of network monitoring and system management
Support interconnection of Field Area Networks
Specification
Tier 1 Field Area Networks Deployment
Provide controlled access from field-located devices or from subtending
Tier 2 Field Area Networks
Provide high network performance commensurate with applications
(from one to tens of Megabits, low latency, sufficient reliability, and
redundancy where appropriate)
Justification
To provide general multi-purpose
connectivity and access services
to field devices so that they can
connect to data/control centers,
distributed applications (perhaps
at substations), and to other fieldlocated endpoints (for peer-topeer communications)
Support virtualization capabilities to maintain traffic segmentation

Aggregate and deliver traffic to places where grid intelligence has been
distributed
Require the spectrum to be under autonomous control by the utility
when wireless networking technologies are deployed
Provide the highest degree of network monitoring and system
management
Support interconnection of Tier 2 Field Area Networks
Tier 2 Field Area Networks Deployment
Provide controlled access from field-located devices
Provide network performance commensurate with applications (from tens
to several hundred kilobits, application specific latency, sufficient reliability,
and redundancy where appropriate)
Support data and control services
To provide purpose-built
coverage and access services to
field devices designed to connect
to data/control centers,
distributed applications (perhaps
at substations), and to other fieldlocated endpoints (for peer-topeer communications)

Aggregate and deliver traffic to places where grid intelligence has been
distributed
Require the spectrum to be under autonomous control by the utility when
wireless networking technologies are deployed
Provide the highest degree of network monitoring and system management
Communications Architecture Standards and Technology Recommendations

Table 14 lists key standards for the Smart Grid communications architecture view. Standards
continually change as technologies evolve; therefore this list should not be considered a comprehensive
or exhaustive list of standards and technology recommendations.
Table 14 - Recommended Communications Standards and Technology
Standards
IEC 61850 family of standards
Describes communication principles, models, and capabilities used to

support applications in electric power systems.
IEEE 1613
Deals with environmental requirements for communication networks

supporting electric power substations.
IPv6
The latest version of the Internet Protocol which has significantly more
address space and enhanced networking features
Multi-Protocol Label Switching (MPLS)
A hybrid data-link/network-layer packet-based transport service used

in Wide Area Networks. Can support circuit-oriented or packetoriented communications. Capable of supporting deterministic traffic.
Offers high degree of network virtualization.
OSI Reference Model
Reference model for describing communication systems using seven

layers of functionality (physical, data link, network, transport, session,
presentation, application). Each layer provides a common set of
services to other adjacent layers.
PHY - MAC standards typical to the various

communication sub-networks:
Each communication sub-network has functional requirements

commonly addressed by using certain types of communication
technologies. While standardization at the network layer and above
helps support end-to-end interoperability, choices must be made at the
physical layer (PHY) and media access control layer (MAC) largely based
on geographic and environmental issues.
Extranet PSTN technologies (ITU-T), SONET/SDH

technologies, Metro-Ethernet
Data/Control Center Ethernet (IEEE 802.3
family), Fiber Channel Protocol (INCITS T11)
WAN SONET/SDH technologies, Metro-Ethernet
Field Area Networks LTE (carrier-provided), IEEE
802.16 (WiMAX), IEEE 802.11 (WiFi), IEEE
802.15.4 (Smart Utility Networks), IEEE 802.3
(Ethernet)
Premises Area Networks IEEE 802.11 (WiFi),
IEEE 802.15.4 (Zigbee), IEEE P1901 (Power Line
Communications)
Management
Smart grid management services generally reside within the cross domain foundational services box in
the lower right area of Figure 9 - Layered Services Tier View.
Management Framework
The Management Framework [Figure 22] presents smart grid management services as a stack of layers
reaching from electrical devices at the bottom to systems management at the top. This should help the
reader visualize the pervasive nature of management services and the resulting architectural scope..
Figure 22 - Management Framework
The architecture is a model with four management layers (MLs). Element ML is at the bottom, the
System ML and Services ML in the middle and Smart Grid ML at the top. Lifecycle and Technology
Management Services are on the Element ML. Event, Asset and Security Management comprise the
System ML. Performance and Policy Management is on Services ML. The Manager of Managers,
performing all services orchestration, is on the Smart Grid ML. The System ML manages Smart Grid
Systems. The Element ML interacts with Smart Grid Communications Elements.
Management Logical Model

The Management Logical Model [Figure 23] contains three views: management component, management
services stack, and management synergy.
Figure 23 - Management Logical Model
In the Management Synergy model (upper left portion of Figure 23), the data sources are at the bottom
and data consumers at the top. The Management Services (middle layer) depict the shared
management services across systems and is divided into three sub-layers. The Lifecycle and
Technology Management Services deal with end devices. The Configuration, Event, Security and
Performance Management Services take data from the layer below, and process the data for
consumption by the Policy Management Layer at the top.
Various utility operations are end-consumers of management services. Operational functions request
Management Services by SLAs and policies. Policy Management orchestrates all management services
per the policies and the SLA. Two broad types are depicted. Data exchanged between end devices are
based on raw standards. The higher data classes are exchanged between Consumers-Processes and
Policy Management to ensure correct SLA and policy rules are being followed.
Management Structural Model

The management structural model [Figure 21] is provided to help the smart grid architect consider
how to best deploy the various management services using a stylized representation of a typical utility
(regulators, interchange and balancing authorities, etc.). At the bottom are the management services
needed by premise devices (smart appliances, PEV chargers, building energy managers, etc.). In
between are a dozen other tiers where management services may be located to support residing devices
and functionality. A self-describing template used for this model is on the last page of Appendix B,
Services Classes Concepts. Included are descriptions of all fourteen tiers used in the model.
Figure 24 - Management Services Structural Model
Management Architecture Principles

The following are architecture principles recommended for developing management architecture:
Management across Systems: The management architecture should support management across
systems. For example, if an urgent (security) need is being addressed to push new firmware to
all meters, the performance management will address contextual needs and inputs from other
systems (such as Volt/VAR, fault management etc.) before the push is performed.
Ease of deployment independent of scale: management architecture deployment should be
ambivalent to the size of the existing systems and the new systems to be deployed.
Support for legacy and emerging systems: management infrastructure must support legacy
(protocols, technologies, devices) and emerging systems
Exhaustive support for management services: management infrastructure shall support all
Smart Grid management services (discussed in Appendix B).
Management operations interface at policy level: The default operations interface of the
management architecture should be at the policy level (giving policies as inputs to the
management architecture), as opposed to configuration level. For example, security
configuration at the element level might be ACL configuration and at a policy level. Multiple
such ACL configurations along with privacy and authentication configurations can be part of a
remote access policy. The security operator must deploy the management architecture to
interface with the architecture giving it the remote access policy as the input as opposed to
dealing with multiple configurations at multiple devices.
Support for input from internal and external entities: The management architecture should
support taking inputs from utility actors (such as actors from generation, transmission,
distribution and consumer functions) and actors external to an utility (such as NERC, weather
systems, etc)
Support for disaster recovery scenarios: The management architecture should support
management services for disaster recovery scenarios such as local management (with out access
to central management resources) and out-of-band management
Architecture Choices
The following are the architecture choices made in support of the above principles:
Hierarchical architecture for ease of operations: a hierarchical architecture is optimal for ease of
operations (policy level management at the top and the element level management at the bottom).
Distributed architecture for support of deployment: data, software (such as firmware and
configuration settings) and intelligence required for Smart Grid elements must be close to end
devices to avoid network bottlenecks during firmware update distributions. Therefore, a distributed
architecture is optimal for Management Architecture.
Modular architecture for support of scale: Management architecture (policy management at the top
and element management at the bottom) requires policy management to remain stable to changes,
and to element additions (Element Management Layer) to the Smart Grid infrastructure. Therefore,
the management architecture should be a modular architecture with support for multiple types of
management at the element management layer would fit into the policy management layer
Architecture Standard and Technology Recommendations

The following table of management standards and technology recommendations is provided to the
smart grid architect for reference. Over time, however, innovations will inevitably diminish its
completeness. The architect should always research the latest information on these topics, but this table
is a good starting point. Table 15 lists important 2011 standards and technology recommendations
applicable to management, each with a brief explanation of their purpose or relevance.
Table 15 - Recommended Management Standards and Technology
Technology
Justification
SNMP V3 for get/set configurations of smart

grid elements
Syslog for logging capabilities of smart grid
elements
IEC 61850 suite for common configuration
across electric and communication devices
Netflow for event and behavior analysis
XML based standards for complex device
management
NETCONF
SSL and SSH for device-level configuration
SNMP V3 has embedded security and provisions for encryption

SNMP is widely deployed across network devices of various technologies.
Syslog standard can be exported securely.
Many parsing functions are available for syslog.
IEC 61850 is well-defined and becoming the standard for electrical and the
communication devices that interface with those electric devices.
Netflow is a simple protocol.
Netflow is suitable for behavior analysis.
XML is becoming the standard for:
Substation Configuration Language:
CIM: CIM is based on XML
SOAP for configuration
NETCONF
XML is slow because of the parsing involved,
NETCONF is the IETF protocol for manipulating and installing configuration
files base
CLI-based configuration should be done through secure versions of
management protocols such as SSL and SSH.
6.
Summary
Introduced less than 50 years ago, Information and Communications Technology (ICT) Architecture
remains a relatively new discipline. Unlike architectural disciplines dating back to ancient times, those
that produced the many human artifacts we use and tend to take for granted today, ICT has relatively
limited experience with the materials it employs. While many classes of information and
communications materials are now stable and well understood, some ICT aspects continue to evolve
quickly. Thus, it is not surprising that Smart Grid Architecture, being even more recent than ICT, must
proceed while its building blocks remain untested in large-scale utility deployments.
This document is one of the first end-to-end Smart Grid Reference Architecture descriptions developed
in North America. Unlike many existing technology-dependent smart grid frameworks, the intent of
this work was to develop technology-neutral smart grid architecture, and to document methods and
recommendations for utilities continued reference as smart grid technologies and applications mature.
Several conclusions became evident while this document was being debated and written:
1. The architecture and resulting infrastructure must be based on layered services architecture
principles. As new ideas and applications emerge, it is critical for the architecture to not only
evolve with them, but to support them with little or no re-working.
2. Interoperability is key. Many vendors will develop pieces of equipment, software and other
items to be integrated with the grid. True interoperability is critical to reducing the cost of
adding each item to the mix. It also lowers the threshold for testing innovative ideas if the
interoperability testing setup cost is too high, new ideas die on the drawing board.
3. Data flows from many sources to many applications. This data interweaving requires an ability
to move massive volumes of data quickly. Data exchange between applications must also be
segregated based on operational needs. An infrastructure with robust data networks, adaptors,
and service busses is critical for a utility to have a fully functional smart grid.
4. A utility based on silo-optimized business functions is incompatible with grid renewal. As
smart grid systems must interoperate seamlessly, so must the underlying business functions.
This architecture document can help the Old Grid evolve into a Smart Grid as legacy grid
infrastructure is merged with the latest ICT. It recommends high-level goals and principles to guide
those tasked with developing smart grid architecture. Additionally, it describes a highly flexible,
adaptive architecture critical for grid transformation. If properly planned, existing ICT infrastructure
operations will continue while infrastructure complexity remains manageable as capabilities are added.
Demands on each utilitys smart grid will change as results from experiments and demonstration
projects become available. Smart grid architectural demands will also change as new applications
evolve. Finally, many unknown factors will impact the Smart Grid ICT architecture over time. For all
these reasons, this document must be revised periodically to remain useful.
Summary 59
NOTES
Summary 60
Appendix A. System of Systems Design Patterns

Smart Grid
System-of-Systems Architectures
System Evolution to Guide Strategic Investments in Modernizing the Electric Grid
K. Mani Chandy, California Institute of Technology
Jeff Gooding, Southern California Edison
Jeremy McDonald, Saker Systems
Introduction
The electrical power system which has served humanity efficiently for a century must now evolve to
meet changing requirements: increasing renewable energy sources, decreasing fossil fuel usage,
managing greater total demand, using electricity to fuel transportation, enabling more customer control
of both demand and supply, dealing with security threats, and adapting to disruptive technologies. An
established industry must adapt to rapid, unaccustomed rates of change.
System of Systems Architectures
Smart Grid designers face the challenge of planning the evolution of the grids architecture from its
current instantiation to meet the needs of a changing uncertain future. This challenge can be met by
managing the evolution of the grid as a System of Systems (SoS). A plan for the systematic evolution of
Smart Grid architecture, as a System of Systems, should be the basis for: developing requirements and
standards, making design decisions, procuring solutions, and managing the Smart Grid over the
coming decades.
A SoS is defined as a collaborative set of systems in which its components: 1) Fulfill valid purposes in
their own right, and continue to operate to fulfill those purposes if disassembled from the overall
system and 2) are managed (at least in part) for their own purposes rather than the purposes of the
whole. The components systems are separately acquired and integrated to form a single system but the
components maintain a continuing operational existence independent of the collaborative system.
Consequently properties, which do not belong to any of the constituent parts, will emerge from the
combined system of systems. Moreover, the system of systems evolves as constituent systems are
replaced.
System of Systems Design Patterns

Appendix 1
Central Principles of System of Systems Architecture

Architects must enforce the following two central principles of SoS to ensure that the Smart Grid is not
overwhelmed by change:
The complexity of the SoS framework does not grow as constituent systems are modified, and SoS
concepts for integrating constituents remain unchanged even as components are added and removed.
The constituent systems do not need to be re-engineered as other constituent systems are added,
removed, or replaced.
These ideas are not new and form the basis of engineering design in many domains including software.
We show how to evolve the architecture of the Smart Grid in a systematic, evolutionary manner, by
adhering to these well-tested principles.
This paper describes four Smart Grid SoS architecture patterns and their benefits and risks. In this
paper we propose a specific evolutionary trajectory for the architecture of the grid as it takes on
characteristics of these four patterns. Tradeoffs between different evolutionary trajectories are
discussed, and the risks in the specific plan we propose are described in detail.
Trends that Impact Evolution of Grid Architecture
We next list trends in technology that impact the Smart Grid and show how these trends impact the
systematic evolution of grids architecture.
A System of Everything: The Smart Grid is evolving to include control of many devices that were not
considered in designs of the current grid; these devices include distributed energy sources and storage,
electric vehicles, and appliances. Smart Grid architecture must consider integration at some level of
widely different kinds of systems that deal with all aspects of life from transportation to healthcare. We
use the hyperbole, system of everything, to make the point that the grid is one of the focal points by
which individuals and organizations monitor and control their lives.
The Penetration of the Internet and the Web: Large segments of the public use the Internet as a core
technology for their work, social networking and recreation. Widespread access to broadband and
increasing use of smart phones and tablets has resulted in large segments of the public, especially the
young, viewing the Internet as a system of everything. This view is likely to strengthen as todays
young enter the workforce. Worldwide penetration of Internet and cellular data technologies will
continue to make these technologies more powerful and affordable.
The evolution of the Smart Grid architecture will reflect evolution of Internet architecture because the
public will not want two competing systems of everything. Moreover, consumers and organizations
Appendix 2
will want tighter control of their electrical devices as energy tariffs based on time of day become
common and they will expect to manage their devices using the same Internet protocols that they use
for other activities.
Continuous Evolution of a Heterogeneous Smart Grid: The information infrastructure supporting the
grid will remain highly heterogeneous for several reasons. Different grid functions have widely
different systems characteristics such as requirements for security, timeliness, and bandwidth; for
example these requirements are very different for fault protection and metering, and for demand
response in homes and data centers.
The Smart Grid will evolve continuously over decades; there will not be a single massive replacement
of the current grid. Information technologies for sensing, metering, actuation, communication, and
computation are developing continuously and rapidly. So, there is no ideal single point in time for a
wholesale replacement of all devices. The architecture must be designed for continuous adaptation.
Next we discuss the costs and benefits of using different SoS architectures at different points in the
evolution of the Smart Grid
Smart Grid SoS Architecture Patterns
The Silo Architecture
The current SoS architecture of the electric grid can be characterized as a collection of silos. Different
functions of the grid such as billing and energy distribution use different information silos that are
integrated by a thin IT layer. The silo architecture worked well for utilities for decades because each
silo served the needs of a business unit, and different business units in a utility had very different
needs. Utilities operated efficiently with little integration across silos.

Appendix 3
Figure 25 - Silo Architecture
The silo architecture, though adequate in the past, will be inefficient for the future for several reasons.
One reason is the increasing demand by a number of stakeholders for a greater control of energy usage.
From the 1960s to 2010, utilities and ISOs controlled generation and distribution, and they specified
well-defined interfaces to consumers: Customers turned switches on and off, paid bills, and called
utilities when power failed. In the future utilities will coordinate activities by multiple stakeholders
across multiple interfaces. For example, integrating distributed generation requires new interfaces. If
the silo architecture is retained then separate interfaces will have to be developed between each type of
stakeholder and each type of silo. Moreover, these separate interfaces will have to evolve separately as
requirements evolve. Our challenge is to design an evolutionary path from todays silo architecture to
an evolving SoS architecture.
Appendix 4
Integration using Enterprise Services Buses
Figure 26 - ESB Architecture
A step in the evolution is to integrate the back office using an ESB. Some utilities are taking this step.
Though the step appears simple, it requires considerable cost, time and effort from IT staff and
business units. Most importantly, integration using an ESB requires discipline that enforces enterprisewide standards on data models and IT services. If this discipline is not enforced, the ESB merely serves
as an integrated physical communication opportunity, but all the problems of the silo architecture
remain.
Integration of the back office results in considerable efficiencies in utility operation. Back office
integration does not, however, solve problems of multiple interfaces between different types of agents
Appendix 5
who will participate actively in consuming and producing electrical energy. Moreover, the ESB
architecture doesnt move towards the utility customers need for an integrated system of everything.
Thus, the ESB architecture is a good step, but not the final step, in the evolution of Smart Grid
architecture.
Adapter Architecture
Figure 27 - Adapter Architecture
A possible next step in the evolution of the Smart Grid SoS architecture is that proposed for networkcentric warfare by the Department of Defense. A central feature of this architecture is that it provides
each participant a user-defined operational picture (UDOP) for situational awareness. As a battlefield
situation unfolds, possibly in unpredicted ways, UDOP provides each warfighter with the information
that he or she needs, while ensuring that warfighters are not overloaded with data irrelevant to their
Appendix 6
operations. DoD is using network-centric architectures to integrate army, navy, marine and air force
operations to help provide overall situation awareness.
Major benefits of this architecture are the enforcement of protocols that guarantee:
Security throughout the system and
Rapid delivery of high-priority information.
The DoD enforces standards on its vendors: New IT components are designed and tested to guarantee
system-wide security and performance.
The challenge for utilities is to derive the benefits of DoDs network-centric architecture while dealing
with a marketplace that is very different from DoDs operational environment. The Smart Grid consists
of a collaboration of multiple utilities and ISOs. As the electricity grid gets increasingly integrated
across states and even countries, the number of collaborating utilities and ISOs will increase. New
types of stakeholders, such as manufacturers of electric cars, distributed energy generators, and energy
storage devices participate in designing new interfaces to the grid. Control by a single agency of multistate, multi-national, multi-vendor integration, while possibly desirable, is more difficult to implement
in the Smart Grid than in the DoD.
The adapter architecture has critically important features; notably it supports the continuous evolution
of a heterogeneous system of systems. The architecture does not, however, adequately meet the
publics needs for a system that integrates all devices. Nor does the adapter architecture sufficiently
exploit the huge opportunities provided by open Internet technologies. Protocols layered on top of the
Internet are not ideal for all applications; however, these protocols will evolve over time to meet needs
for security, performance and other features required by many applications including the Smart Grid.
Though the adapter architecture goes a long way towards meeting Smart Grid requirements, the
architecture doesnt go far enough to meet the technological or societal needs of a utilitys customers.
Architecture Based on Open Standard Service Mechanisms
A great deal has been written about Service-Oriented Architecture (SOA). A definition of SOA, offered
by Roy Schulte of Gartner who coined the term, is that an SOA system satisfies the following five
principles.
1. Components can be added, replaced or modified individually without affecting the remainder of the
system.
2. Components must be distributable, i.e., run on arbitrary servers and communicate with each other
by messages or service invocations.
3. Component interfaces must be defined using standard metadata and the interfaces must be
discoverable by application developers.
4. A component can replace another with the same interface.

Appendix 7
5. Services can be used multiple times by disparate applications or the same application.
These characteristics also satisfy the two main principles of System of Systems architecture.
Services may be organized in business domains so that some services are only available to others
within the same domain; however, a central point of standard services is common metadata for service
interfaces regardless of the business domain in which the service lies.
The Adapter Architecture is a service-oriented architecture. The central differences between adapter
architectures and one based on standard open services are the protocols by which services are invoked.
Since the IT infrastructure for the Smart Grid will need to take steps towards satisfying customers
needs for a System of Everything, we are faced with two options.
Ensure that the mechanisms for specifying, invoking and maintaining services for the Smart Grid are
the same as, or consistent with, mechanisms for invoking other services.
Have two mechanisms for managing services, one for the Smart Grid and the other for everything
else, and build bridges between Smart Grid and everything else.
There are advantages and disadvantages for both approaches. An advantage for the two-mechanism
approach is that a Smart Grid IT infrastructure is designed specifically for the particular needs of the
Smart Grid. A disadvantage of this approach is that all the thousands of utilities and other agents
participating in the Smart Grid will have to adopt either a single standard (or a very small number of
standards) designed specifically for the Smart Grid, and build integration layers between the Smart
Grid standard and protocols to manage both business and personal needs in other domains.

Appendix 8
Figure 28 - Service-Centric Architecture
The development of a Smart Grid system of systems based on Internet (e.g. REST) or Web-services
protocols requires an understanding of the key points of interoperability across the entire Smart Grid.
The silos in the current infrastructure can be architected in layers, with layers across different silos
having the same interface. The new architecture must specify standard interfaces at each layer so that
different business functions are architected in the same way and reuse components. The architecture
must also specify common services such as network management, security, and diagnostics, and these
common services should be accessible to all systems and devices used to execute different business
functions.

Appendix 9
Summary
Strategic investments in modernizing the grid must be based on a plan for transitioning todays silo
architecture to a system of systems architecture based on widely adopted standards, common services,
and loosely coupled systems. Strategic investments will pay off only if they designed for a carefully
planned trajectory of grid architecture.
Successful execution of a transition plan requires early and continuing investments in Smart Grid
standards, unified infrastructure and the co-evolution of processes to support migration from
centralized to distributed operation. Massive changes in architecture, operations, and training will be
required over the transition period. So, a utility should adopt an evolutionary approach that doesnt
exceed the utilitys capacity in these domains.
A transition plan that some companies have adopted is to first move from a silo architecture to an
enterprise service bus (ESB) architecture and then move incrementally to an open-standards based
architecture, developing and adopting standards and common services in steps. The utility should,
however, have an overall architecture transition plan, including designs for system-wide security and
system-wide timeliness at every step of the plan, before making incremental changes.
Each of the four architectural patterns discussed in this paper has benefits and risks. Each transition
from one architectural pattern to another has substantial costs, takes time, and requires expertise in
both the grid and IT architecture. Utilities must, however, develop architecture plans before making
strategic investments in the grid.

Appendix 10
Appendix B. Services Classes Concepts

Applications Services
As discussed previously, the utility industry is being transformed by Smart Grid initiatives.. This
transformation affects functional business processes, as well as associated technology and applications.
These changes will lead to a re-engineering of how these applications are used and interact with other
domains. Applications will be transformed to leverage shared services to better allow the utility
business domains to interchange available information. Interoperability and loose coupling between
application functionalities is best assured if the application services interact through well-defined
interfaces based upon standards, e.g. IEC 61968 and IEC 61970.
Smart Grid architects, over time, will disaggregate monolithic systems into smaller atomic functional
components. These will be used to aggregate, compose, choreograph and orchestrate business
processes leveraging smaller atomic functional components. The optimizes assets and operates efficiently
baseline Smart Grid goal requires applications to be designed for maximum flexibility and reusability.
If applications are adequately service enabled, the design of flexible, smart grid processes can leverage
industry standards such as BPEL (Business Process Execution Language). For example, suppose a giant
distribution management system is decomposed into many smaller functional components, each with
small functions implemented as self-contained services. A utility functional section can, through BPEL,
rapidly devise business processes by orchestrating a set of services to perform a business process. Since
the services are designed for re-use, another business group could devise a similar process using the
same services orchestrated in a way to best meet its particular business needs. Business analysts can
design a multitude of different business processes by assembling the same functional components into
different combinations. This approach provides analytics needed to measure process efficiency since
properly designed services include introspection and self-testing. Analytics to tune process efficiency
can be implemented with each process piece, and re-used by every business process using the services.
P1
Service A
Service E
P1
P2
P3
P2
Service I
Service B
Service F
Monolithic
Application
P3
Service J
Service C
Service G
P4
Service K
P4
Service D
Service H
Figure 29 - Dis-aggregation of a Monolithic System

Services Classes Concepts

Appendix 11
Functional Aspects of Application Services

The Operations functional domain manages the movement of electricity through the efficient operation
of the power system. It therefore impacts many other business domains:
a. Network Operations: includes supervision of substation topology and control equipment status,
network connectivity, loading conditions, fault management, outage management and location
of field crews.
b. Network Extension Planning: develops long-term plans for the adequacy and reliability of the
electrical networks needed to fulfill evolving energy usage needs.
c. Operations Planning and Optimization: includes the definition, preparation and optimization
of workflows, plus the operational sequences required for the maintenance, monitoring and
control of networks.
d. Metering: performs reading of the information recorded at customers service points; sends
alerts and notifications; controls customer equipment interfaces.
e. Record and Asset Management: includes electrical substation and network assets either owned
by the utility or having legal responsibility for.
f. Maintenance and Construction: addresses functional needs for equipment to perform better
and extend its service life.
g. Customer Support: manages operational aspects of customer interfaces such as trouble calls,
point of sale, account management, etc.
h. Enterprise Systems: supports the overall utility businesses, including, but not limited to, human
resources, corporate finances, and supply chain management.
i. Bulk Energy Management: serves Generation and Transmission Control, Topology Processing,
Account Settlement, Market Operations, Load Management, Energy and Transmission
Scheduling, Dispatcher Training Simulation, SCADA (Supervisory Control And Data
Acquisition), Alarm Processing, etc.

Appendix 12
Figure 30 - Functional Services Organization
As discussed above, the Operations domain boundary includes an edge to most utility domains and
thereby can provide a large set of application services.
As an illustrative example, consider the application services offered by the Network Operations
Planning and Optimization. The related services can be classified into three sub-categories, which can
be further decomposed into various functional, modular and reusable components or services:

Appendix 13
Figure 31 - Network Operations planning and optimization
The Network Operations and Optimization Application Services are:

Load Forecast Service: The Load Forecasting function predicts short-term, mid-term and long-term
system loads and maintains a real-time forecast and a study forecast. The real-time forecast is based
on actual historical load and weather data and generates a load forecast for the current minutes,
hour and day. The study forecast uses a completely independent set of historical and predicted data
the operator may configure to evaluate hypothetical situations in the future.
Power Flows Service: This service provides the calculation engine for external systems to estimate
the network conditions based on provided network status and measurements. This service is used in
real-time to provide dispatchers with an accurate and precise estimation of current network state.
This service is also leveraged by advanced network features requiring real-time base power flow
results for further analysis, (e.g. Contingency Analysis, Volt/VAR Control, or FLISR Fault Location,
Isolation and Services Restoration). This service can also be leveraged by Network Planning
engineers to determine the effects of control actions (breaker switching, tap changing, and
interchange adjustments).
Contingency Analysis Service: This service enables the real-time study of the effects from a system
component failure. Contingency analysis relies on the Incident Simulation Service to model the
effects of identified contingencies. Once all relevant contingencies have been simulated, the

Appendix 14
Contingency Analysis Service ranks the results based on the current network conditions to inform
the grid operators of areas of possible risks or congestions. The Contingency Analysis Service can
also be in used in an engineering exploration or training environment.
Short-Circuit Analysis service: This service is responsible for analyzing short circuits in
transmission and distribution networks. These include single line to ground, line to line, double line
to ground, three lines to ground, single line open, double line open, etc.
Optimal Power Flow service: This function allows dispatchers or network planning engineers to
optimize power system control actions based on given criteria (flows of real or reactive power,
switching of compensation devices, optimal settings for voltage control, etc.). In optimal power flow,
the control actions are automatically predetermined within the limitations of the power system.
Supply Restoration Assessment Service: This service analyzes the switching options after a
network fault is identified in order to restore the power for as many customers as possible in the
shortest time possible. In distribution systems, this service is generally invoked by the Fault
Location, Isolation and Services Restoration service to provide alternate switching plans for the
operators to manually or automatically select for restoring power to customers when the normal
feeder configuration does not allow the supplying power to affected customers.
Switching Simulation Service: This service enables the simulation of switching operations. This
service is leveraged by many other services, in both real-time or study environments. For example,
the real-time Supply Restoration Assessment Service calls it to simulate the switching steps
necessary to isolate faulty devices or restore power to customer. Another example, in the training
environment settings, when the trainee operators issues a supervisory control, the Operator Training
Simulator calls the Switching Simulation Service to operate the selected devices.
Incident Simulation Service: This service provides the ability to simulate and recreate an incident
on the network for analysis or training purposes. This service leverages the Switching Simulation
Service to perform switching steps on the network and on the Power Flow Service to compute the
resulting network conditions. The Incident Simulation Service is leveraged in both real-time and
study mode environments. For example, the Operator Training Simulator heavily relies on this
service to drive the simulated network state and conditions.
Weather forecast analysis service: Weather is monitored to predict impacts on the electrical
networks, especially where outages are likely to occur due to heavy storm activity. Temperature and
wind speed are sometimes used to calculate dynamic load limits on electrical network assets.
Fire risk analysis service: It analyzes the risk of fire in the network. For example, thermal rating of
network equipment. There is a certain temperature for which transformers may be at risks of
malfunctioning, failing or worst, exploding.
Define operational limits service: It defines operating limits for monitoring operations of the
transmission and distribution facilities.
Thermal ratings of network equipment and lines: Changes in electrical asset performance limits
based on temperature and wind speed and current season. This is distinguished from Asset
Investment Planning (AIP) counterpart, which includes new construction and re-conductoring.
For all these services to properly interact and fulfill the utility objectives, an integration layer is
required to ensure the orchestration and communication of these services. The next section describes
these integration services.

Appendix 15
Integration Services
Integration services and patterns are very important in reducing ICT complexity while allowing it to
quickly and easily deliver on business needs while enabling continued innovation. Integration services
leveraging the enterprise service bus pattern (1) offer ways to cut down point-to-point connectivity; (2)
maintain a higher level of reliability; and (3) improve flexibility in the architecture. The presence of an
ESB is fundamental to simplifying the task of invoking services services can be used wherever needed
from wherever they reside within the enterprise; used without specific knowledge of where the
services reside or how to transport requests across the network to invoke those services. Some of
common capabilities needed in integration services are routing and brokerage, mediation, protocol
conversion, namespace translation, service virtualization, and aggregation.
Business Process Orchestration and Choreography Service

Business process choreography and orchestration capabilities, associated with the composition and
coordinated execution of services, provide flexibility in building new processes and managing process
change. Business process execution language (BPEL) is one of the standards used for building
orchestrated ICT-enabled business processes. Once developed, the process is deployed on servers
running a BPEL engine and utilized by business systems shepherding the processes for the enterprise.
Choreography is used when more complex behavior is needed, with each atomic-process reacting to
the actions of other processes using pre-established heuristics, without central coordination.
Business Rules Services
As ICT Systems began supporting ever increasing, ever changing business processes, events and
decisions, the need to identify and manage business rules became obvious. The rules needed to reflect
business policy in a form comprehensible to business users and executable by a business rules engine.
Separating the business rules from application code simplifies system changes, allows re-use of the
rules across applications/processes, and supports rapid rules selection and execution.
Registry and Repository Services
The registry functions provide publication of metadata about the function, requirements, and semantics
of services allowing service consumers to find services or to analyze relationships between services.
The repository function provides the ability to store, manage, and version service metadata.
Business application services
Business application services provide ability to deploy and manage robust, agile and reusable SOA
business applications and services of all types. These are service components designed specifically as
services within a business model and represent the basic building blocks of the utilitys business design
services not decomposable within the business model, but composable to form higher level services.
This allows creation of new services and service enablement of legacy packages and applications. These

Appendix 16
services allow the user to develop innovative applications through their support of open standards and
programming models, including: OSGi, CEA, JPA, SAML, SCA, SDO, SIP, Web 2.0, and XML.
Gateway Services
Gateway services provide filtering and data stream processing, receive all events from the device and
send control commands to device. They also act as interaction services for machine to machine
interaction, control access to applications, services and data based on customizable roles and rights
thereby enable consistent enforcement of security and governance policies. These services also enables
web integration services through the support of Web 2.0 technologies with JSON filtering and
validation
Complex Event Processing (CEP) Services
Complex Event Processing services provide the ability to simultaneously access and analyze thousands
of data streams from both inside and outside the corporate firewall and delivering the result directly to
business application services. It supports events conformant to the Common Base Event specification
and other messaging formats. It extends the one message at a time paradigm by detecting complex
situations involving composition of messages/events sensitive to context (i.e. semantic, temporal,
spatial, spatio-temporal, or scope).
Workflow services
A workflow service provides automation of a series of tasks assigned to application users based on
their roles. When the application containing the workflow is instantiated, a user is assigned a task
based on his or her role. This service is used for developing simple service composition. When
complex, parallel service composition is required, workflow is best served by choreography services.
CIM Binding Services
The Common Information Model (IEC, 2003) is a key standard in the utility business domain. To
expose a business service, this binding service maps the CIM model with backend data attributes. This
service provides a CIM data model to handle the large portfolio of existing and extensible CIM classes.
Visualization Services
Visualization services include presentations of grid topology, alarms, switching state, and business
capabilities. Presentation often is tailored to role-sensitive contexts system behavior and visual cues
adjust based on user job role and, perhaps, user location. To address the risk of data overload,
presentation services can help transform the flood of smart grid data into nuggets of information
presented in an optimal format for grid operators to make appropriate decisions. Thus, visualization
services are essential to Smart Grid decision support systems.

Appendix 17
Web Integration Services

There are many characteristics of Web Integration (i.e. Web 2.0) services such as web as a platform,
harnessing collective intelligence, lightweight programming model, software above the single device,
light weight user interface apply to smart applications. There are multiple applications of concepts of
these services within utility domain (i.e., mashups) to build visualization and situational services,
aggregation of usage, including PEV charging usage and customer information etc.
Cloud Services
The cloud computing architecture is a flexible computing platform implemented with a highly
virtualized, automated and service-oriented design. Utility companies can leverage cloud computing
for rapid, real-time access to considerable computing power, immense storage and numerous
applications. By using cloud computing, utilities can improve new application development and
deployment and quality of service. It also enables prompt response to evolving consumer priorities and
market challenges on a utilitys core products. As agility is key to future business success, and cloud
computing provides ICT agility, cloud services may fit well in utility System of Systems architectures.
Cloud computings inherent reliance on standardization will increase operational efficiency. Public
clouds drive process standardization by identifying scalable workloads able to be managed in mass.
Private clouds leverage the scale inherent in existing utility hardware by dramatically improving asset
utilization. Rather than deploying and maintaining multiple application instances, cloud computing
enables standardization on a single instance. Standardization on this scale significantly reduces labor
and other ICT operating expenses while increasing availability. Similarly, highly virtualized
infrastructure reduces ICT capital expenses, consolidates data center resources and reduces
investments in hardware and facilities.
Non Functional Aspects of Application Services

The issues of High Availability, Performance and Scalability are key architectural concerns for all
enterprise architects, particularly for Smart Grid architects. As enterprise ICT architectural approaches
are increasingly applied to the grid, solution resiliency increases in importance. These issues are highly
interrelated and often impacted by technological, temporal, spatial and budget constraints.
Additionally, there is limited precedence for the Smart Grid architect to rely upon, and the domain is
rapidly evolving. This section addresses these aspects by defining terms and their inevitable trade-offs.
Performance and Scalability

Performance has two facets. The first is the speed the system supports a single request. The second,
system throughput, is the number of simultaneous requests supported with acceptable response times.
Scalability is a measure of how well the system accepts higher volumes with acceptable performance
and availability. A scalable architecture allows a system to grow with reasonable hardware and

Appendix 18
software accommodations. In contrast, growth of a non-scalable architecture requires major changes to

subsystems, hardware configurations, or new processor types.
Performance and Scalability approaches are highly interdependent. High availability and performance
goals can be achieved by paralleling system components, resulting in load reduction and response
improvement for any element. Generally, additional units can be easily added if the architecture has
the units paralleled. At the same time, improved availability is enabled by the presence of redundant
hardware in this architecture. An architecture using parallel elements can also apply dynamic Quality
of Service rules to ensure critical transaction completion when components are compromised.
Analytic Services
Analytics are data transformations used to extract information actionable by systems and people. As
such, some analytics are cyber (machine-to-machine), while others are used for decision support after
appropriate presentation (machine-to-human). The scope of analytics includes:
Basic database queries for routine operational and business process issues
Real time streaming data transformations used in closed-loop control systems
Large scale data visualizations used for operator decision support
KPIs and dashboards used for executive review
Reports for submission to regulators
Data mining for system planning and asset management
Many Smart Grid analytics are used to transform raw grid-derived data into a high-level depiction of
grid state, supporting total situational awareness. Grid state includes knowledge of operational
electrical parameters, device/system status, power quality, stress factors, and loading conditions. This
grid state information is embedded in low-level data too voluminous and detailed to be
comprehensible or actionable. Analytics extract the essential meaning from the data at the numerous
grid intelligence tiers, from Protection & Control to System Planning & Optimization.
As information and system complexity increase, presentation sophistication must necessarily increase.
For some target audiences, reports or dashboards are inadequate. Advanced visualization capabilities
are often needed to present analytics derived from sets of large, complex and dynamic data.
Types of Analytics
A wide variety of Smart Grid analytics exist, and more are constantly being developed. These analytics
can be categorized in multiple ways, but one in particular is helpful. Figure 32 below depicts a
taxonomy of Smart Grid analytics.

Appendix 19
Figure 32 - Smart Grid Analytics Taxonomy
The taxonomy has six major classes of grid analytics, all driven by data from grid devices and systems.
The classes support three high-level intelligence categories: Technical and Engineering, Operational,
and Business.
Signal Analytics
Signals are the lowest level data coming from grid sensors. Therefore, Signal Analytics are often the
"earliest" analytics (the ones first applied to raw data) and generally take the form of digital signal
processing functions. The Signal Analytics profile follows:
Example Usage: transform voltage and current waveform samples into Root Mean Square (RMS)
values, along with real and reactive power, Total Harmonic Distortion (THD), and other relevant
characterizations
Data Frequency: real-time, may be hundreds of waveform samples per cycle over multiple channels
for three phase voltages and currents.
Data Types: integer digitized values, later converted to float engineering units
Analytic Processing Frequency: ranges from per sample up to typical SCADA data rates (e.g. four
second cycle time)
Event Analytics
Events are discrete, real-time messages from grid components caused by temporal or value limits being
reached (logs, alarms, alerts). The Event Analytics profile follows:

Appendix 20
Example Usage: processing power outage notification message bursts from smart meters during an
outage or voltage sag
Inbound Data Frequency: real-time, can be thousands of events within a few seconds
Data Types: numerous event message formats
Analytic Processing Frequency: real-time to manage bursts with low (millisecond to second) latency
without message loss
Result Set Publish Frequency: per event, asynchronous
State Analytics
State data from the grid supports real-time utility network analysis, monitoring, and control. The State
Analytics profile follows:
Example Usage: monitoring and control of grid power flows
Inbound Data Frequency: real-time, from per cycle up to typical SCADA data rates (e.g. four second
cycle time)
Data Types: various SCADA and sensor formats
Analytic Processing Frequency: real-time as per control system requirements; can be SCADA cycle
time or as fast as GOOSE message times (4 msec max latency)
Result Set Publish Frequency: SCADA rates to minutes for most processes; milliseconds for
protection and control functions
Engineering Analytics
Engineers need analytics to perform long-term planning and operational analysis. The Engineering
Example Usage: circuit and substation planning
Inbound Data Frequency: real-time - mostly SCADA data rates
Data Types: usually floating point values from circuits, customer usage data records, maintenance
event logs, waveform files
Analytic Processing Frequency: quarterly, yearly, multi-year
Result Set Publish Frequency: on demand as planning and analysis processes are performed
Operations Analytics
Operations depends on analytics for short-term optimization of asset effectiveness. The Operations
Example Usage: all aspects of asset management for utilities, including asset health assessment via
remote monitoring, asset stress accumulation monitoring for support of condition-based and
predictive maintenance, and asset utilization, both in real-time and for system planning.
Inbound Data Frequency: real-time at SCADA data rates or slower; directed mostly to historian
databases, except for data used in load balancing and optimization.
Data Types: floating point sensor readings and integer operations counts
Analytic Processing Frequency: SCADA rates for real-time control functions; as needed for analysis
reports
Result Set Publish Frequency: same as Analytic Processing Frequency

Appendix 21
Consumer Analytics
Utilities better serve their customers by analyzing data on electric producers and consumers
(prosumers). The Consumer Analytics profile follows:
Example Usage: all aspects of prosumer interaction with the utility, from billing and complaint
management to interface for distributed energy resources, demand response (DR), and pluggable
electric vehicle charge management.
Inbound Data Frequency: rates for meter reading, DR feedback and prosumer interactions are slow
compared to grid operations; may be minutes to months
Data Types: meter usage data, DR data (Smart Energy Profile), event log messages
Analytic Processing Frequency: on demand, mostly monthly or longer; some analytics for DR may
be from minutes to hours
Result Set Publish Frequency: on demand
Smart Grid Data Classes

Given the many potential sources of power grid data, for analytics and data management purposes it is
helpful to classify them into seven categories. These categories aid the proper implementation of
analytics, the design and placement of data persistence elements, and the sizing of communication
network elements.
Operational data
Operational data is mostly real-time state measurements of circuits and devices. As this data changes
from moment to moment, most analytics are concerned only with present data values. This data is
persisted in various ways, primarily by overwriting old values. A log may be kept by placing snapshots
of operational data in a time series (historian) database.
Non-operational data
This data category has telemetry used to monitor remote assets: equipment condition, environmental
monitoring, stress indicators, etc. Most of this data is collected on a regular basis and persisted in a time
series database.
Meter usage data
Besides its obvious use for meter-to-cash, meter data is often input to various technical and business
analytics. While some analytics could use the default meter data repository, this approach may not
scale well for more advanced, real-time analysis. Alternate data services could therefore be necessary
for some metering analytics.
Event streams
Many Smart Grid devices produce asynchronous event messages. Analytics for such data streams may
need special processing tools (Complex Event Processing engines) to quickly respond to periodic data
bursts from grid devices. Event messages may also be logged for post-mortem analytics.

Appendix 22
Waveform data
Waveforms are often produced by grid devices based on some event or condition. This data are
generally collected into files (COMTRADE or PQDIF formats) for post-event analysis. The files are
typically batch transferred into a waveform repository for later use by analytics tools.
Analytics as data
Many analytics are real-time data streams, especially those used for line sensing and remote asset
monitoring. These low-level output streams can be inputs to other analytics. They can also be stored in
a time series data store for later analysis.
Meta-data
A wide variety of grid environmental data give context to actionable information. The architecture
must provide, persist and distribute pertinent meta-data for use by analytics.
Analytics Properties and Issues
Architects should understand fundamental analytics properties and usage issues to properly align
analytics into Smart Grid architecture. This understanding will reveal analytics as more than simply a
set of services provided to the Smart Grid System of Systems.
Analytics as filters
Analytics may be viewed as both filters and data reduction mechanisms. Raw data from grid devices
can be too voluminous for centralized processing. Low-level analytics services effect a data reduction
by extracting useful information to characterize larger data sets while preserving essential content.
Event processing as analytics
Many grid devices generate asynchronous event messages based on a variety of physical and virtual
events. Such event streams contain valuable information but typically arrive in large bursts needing
low latency handling. As most utility systems cannot deal directly with such data, a complex event
processing (CEP) analytics tool is used to simultaneously extract core information while throttling or
filtering event message bursts. An example is the processing of power outage notification message
bursts from smart meters; CEP is used to reduce the burst of raw messages to a single informative
event message representing the underlying physical event. In addition, grid sensor event data streams
can also be marshaled by CEP, such as Phasor Measurement Unit (PMU) data frames. When processed
through CEP, PMU information can be used to detect, characterize and locate fault and pre-fault
transient phenomena in real-time.
Real time analytics for protection/control
Many grid analytics support real-time protection and control operations. Since these analytics are often
characterized by very low latency (as fast as sub-cycle), the data must be processed faster than any

Appendix 23
database persistence can be applied. The data source is therefore connected directly to the analytic, and
the analytics output routes directly to a machine consumer.
Telemetry monitoring
Much of Smart Grid data consists of remote asset and grid state monitoring telemetry. These produce
high data volume with a steady and relentless delivery. Under normal operating conditions, the data is
unremarkable. As monitored parameters trend away from nominal, actions should be taken, but the
large data volume makes it impractical for people to constantly watch the data. A solution is to have
analytics agents continually scan the data for specific conditions or trends, then issue appropriate alerts
and notifications. Defining all possible alert analytics rules is impossible, therefore the analytics agents
should be configurable, with subscriptions made or dropped as needed. End users of the analytics
should also be allowed to perform some configuration. The Smart Grid Architect will need to secure
this flexibility by providing appropriate access control via role-based identity management.
Visualization
Many Smart Grid analytics involve extensive numerical data used in making operational decisions. The
need to present information in an operations-optimized format makes visualization a crucial element of
the analytics architecture. While its overall usefulness to analytics makes visualization is a core
analytical tool, it is also useful to other grid services (data synchronization, workforce enablement,
customer empowerment). This therefore places visualization as a cross-cutting asset in the Smart Grid
architecture.
Concatenated analytics
Many analytics are best structured in concatenated form, where output from one analytic becomes the
input to another. For Smart Grid, this can occur in one of two ways. In a distributed architecture,
individual analytic agents may cooperate in a calculation, with each agent contributing a portion of the
result. Alternately, analytics may be structured in tiers. An example would be the low-level analytics
converting power quality (PQ) information into measures of grid asset stress. The stress analytic output
are inputs to a second tier of analytics converting stress to abstract measures such as Loss of Life,
Expected Time to Failure, and Asset Failure System Risk. These abstract measures are then made
available to an asset management application incapable of processing the original low-level PQ data.
Sourcing of data for analytics
A key issue for analytics architecture is how to best minimize the number of new sensors. Properly
chosen and located sensors can produce grid data capable of supporting many separate business needs
when processed through multiple analytics. This multi-faceted aspect makes necessary a sensing
strategy to accommodate business requirements while minimizing investment in new sensing
infrastructure.

Appendix 24
Delivery of analytics results

In good grid architecture, analytics results will be distributed in various ways. Many analytics can be
used by more than one business process (1:N delivery model). Some business processes require the
combined results of many analytics (N:1 delivery model). Finally, should both situations fit, the N:N
delivery model could be employed. These delivery models need to influence the modeling of any
business process reliant on analytics.
Persistence of analytics
Analytics output, if treated as data, may need some type of persistence. One simple approach is to store
analytics outputs in a time series database (historian). Not all analytical results need to be kept for long
periods of time. For example, analytics used for converting raw grid data to grid state information will
persist until over-written with fresh grid state; the persistence may be in a distributed or shared
database, with individual values lasting only seconds before being refreshed.
Analytics Architecture Considerations
The Smart Grid Architect must consider many factors while developing the analytics services
architecture. This section outlines several key issues for analytics architecture.
Analytics Latency Hierarchy

How analytics outputs are consumed is an important consideration for a Smart Grid system. Some
applications must perform with very low latency in response to events or conditions, whereas others
may respond over days or months. The vast majority fall in the middle, with latency ranging from
seconds to hours. Thus, analytics can be categorized based on a latency hierarchy [Figure 33].

Appendix 25
Figure 33 - Analytics Latency Hierarchy
Classification of an analytic by its latency requirement is an important architectural consideration, as it

may dictate where the analytic must be executed. It also strongly impacts two other Smart Grid
architectural elements: data persistence and communications. The distribution of intelligence in a Smart
Grid system is influenced by latency and scalability. Analytics can also be used to normalize data
bandwidth requirements at various tiers in the network architecture by deploying their filtering
capability in a distributed hierarchal form. The tradeoff between distributed intelligence (and
distributed analytics in particular) and network requirements is a crucial Smart Grid design issue. Data
persistence architecture must align with this tradeoff decision, which can lead to distributed hierarchal
data persistence design issues.
Scalability
As Smart Grids evolve, data volumes will increase and analytics consumers will demand increasingly
more stringent delivery requirements. This evolution will require periodic review of analytic engine
scalability and the sizing of associated architectural elements (persistence and communications). Some
centralized analytics approaches don't scale well, caused either by the engine becoming a bottleneck, or
because the network design prevents the embedded analytics engines to transition from handling
dozens of inputs to thousands, or millions. As described above, the data reduction aspect of analytics,
when coupled with appropriate network architecture, can address scalability in a general way. The
same feature provides an incremental build-out capability compatible with typical utility roll-outs.

Appendix 26
Availability and Failover

Some Smart Grid analytics are crucial to real time operations. Such analytics may require a high
availability (HA) implementation consistent with the critical operational processes supported. The
Smart Grid architect must first classify analytics appropriately and then specify the necessary HA
architectural elements.
Analytics and Data Representation
Analytics architecture is necessarily closely aligned with data architecture, with a focus on two areas:
Persistence models and data stores

Data representation
The first is influenced by Smart Grid data classes and latency requirements. The second is part of a
larger Smart Grid issue. At the lowest levels, Smart Grid devices will produce data in many different
formats and protocols, especially legacy devices. However, even newer devices may use IEC 61850,
IEEE C37.118, DNP 3, SEP 2.0, etc. As data and analytics move up the hierarchy from grid devices
toward databases and application systems, these disparate formats should be converted to the IEC
Common Information Model (CIM) representation. The CIM usage benefits of enhanced
interoperability and architectural "future-proofing" are significant in any Smart Grid design, especially
one based on an evolving System of Systems approach toward Smart Grid transformation. The location
and timing for converting non-CIM representations to CIM are key architectural decisions.
Management of Analytics Environments

Like other complex systems, analytics require management functions for proper deployment, version
control, etc. Analytics configuration issues are essentially the same as those for devices or applications.
For complex event processing, CEP engines are generally rule-based, with the rules taking many forms
(state transition models, extended SQL query sets, etc.). Managing CEP rule sets, including the proper
distribution and synchronization in a distributed analytics environment, is a critical aspect of the
overall analytics architecture. The architect may merge this with the cross-cutting issue of managing
services, systems, and devices to evolve a unified solution for communication networks, grid devices,
and analytics elements, including CEP rule sets.
Centralized, Distributed, and Hybrid Analytics Architectures
Enterprise analytics architectures have traditionally been centralized, with business data repositories
and warehouses, including analytics assets such as ordinary database queries, data cube engine
(OLAP) tools, Key Performance Indicators (KPI's), executive dashboards, and data mining tools. For
Smart Grid, all of the foregoing still applies, but the issues of real time control and operator decision
support must also be addressed. Due to the data volumes and latency requirements supporting utility

Appendix 27
operations, it is impossible for all analytics to reside at the enterprise back office. At a minimum,
analytics are needed in the control centers, and likely beyond.
Control center analytics may be viewed as centralized and therefore logical deployment sites for
analytics engines. Since grid data are often streams, analytics engines must accept real-time data feed,
with access to the meta-data providing context for grid data interpretation. This may require a
combination of calculation engine, CEP engine and visualization package operating in real time. If any
analytical results are used in an automatic fashion, the analytics engines must have network
connectivity capable of delivering these outputs to the consuming systems. This connectivity will also
be needed to allow periodic migration of some grid data and real-time analytics results to back office
data repositories supporting various business analyses, reporting, and planning tools..
In advanced Smart Grid architectures, intelligence and any supporting analytics may be moved outside
of the control center to substations and beyond. One approach is to view key substations as grid data
centers in their own right, with analytics treated in a manner analogous to the control center. Another
approach is to make use of truly distributed models, where analytics elements at the substation interact
and cooperate with analytics at the control center. Finally, a highly distributed edge computing
architecture would push intelligence and analytics beyond the substations to locations near, or on, edge
devices. In addition to edge grid devices, network devices are also logical homes for elements of grid
intelligence and analytics.
The distributed analytics model has compelling advantages in terms of latency minimization,
robustness, incremental rollout, and flexibility. However, the model also raises several issues,
including:
Interaction models distributed analytics may be implemented in embedded dedicated form or
as agents in a multi-agent system. The nature of interactions among distributed analytics
elements is a major architectural issue.
Share models if distributed analytics elements are to interact with each other and with utility
devices and systems, then data sharing models become crucial. These models range from
various kinds of memory sharing (shared RAM, distributed databases, shared-nothing, etc.) to
hierarchal and lattice data flow models.
Peer-to-peer messaging an implication of using distributed approaches for analytics
architecture is the necessity of peer-to-peer messaging for most models. This adds to the
communications network and security design requirements.
Regardless of how analytics are distributed, most models require a centralized mechanism to manage
the distributed analytics. This must be included in the analytics architecture design.

Appendix 28
Analytics Capability Maturity

As with many other aspects of information system architecture, implementation, and operation,
analytics architecture at any utility will progress through levels of capability maturity. A simplified
model of capability maturity for analytics in Smart Grid systems follows:
Table 16 Analytics Capability Maturity Model
Level
Self-learning
Optimizing
Predictive
Description
Comments
Analytics automatically learn from data

and experience to modify themselves so as
to improve accuracy and efficiency in
information extraction and information
discovery
Analytics are used as the basis for
optimization of operations, asset
management, and prosumer interaction
Analytics are advanced enough to make
significant predictions and are routinely
used in a forward-looking manner
Analytics tools include autonomous goal seeking

capabilities aligned with the utilitys business goals
and continually operate to improve their
performance against the large scale goals of the
business
Analytics are deeply integrated with the higher
levels of control and decision-making in the utility
Automated
Analytics processes are fully integrated

and run automatically; most analytics
describe present and recent past
Operational
Analytics are routinely used in operations

and business processes
Data acquisition is integrated to some
business and operational processes
Basic ability to make measurements,
collect data, and generate batch reports
Business/ Operational
Intelligence
Measure/report
Utility processes make routine use of the predictive

capabilities to plan alternatives and perform
tradeoffs; predictive analytics are commonly used
in decision support
Integration of analytics with processes and systems
is extensive; very little manual intervention is
required for analytics to receive data or deliver
results to consumers
Some amount of data and analytics integration is
present; some manual integration still being done
Much of the integration is manual; processes are
still fragile and siloed
Elementary capability; most utilities are well past
this stage
Conclusion
Ultimately, the Smart Grid Architect must provide an analytics architecture consonant with the rest of
the Smart Grid design, and consistent with the System of Systems approach as a set of services able to
evolve with the Smart Grid. The analytics architecture must also be closely coordinated with data
management services, communication services, and security architectures.
Data Services
Data Governance
Data Governance is the discipline of treating data as an enterprise asset. Its goal is to optimize, secure
and leverage data as an enterprise asset. Data Governance uses an organizations people, process,
technology and policy to derive optimal value from enterprise data. It also helps align disparate and
often conflicting policies that are a contributing cause for many data anomalies.

Appendix 29
Treating data as a strategic enterprise asset implies the need for organizations to complete data
initiatives analogous to ones for physical assets. For example, utilities need to build an inventory of
their existing data. The typical utility has an excessive amount of data on grid components, plants,
customers, vendors and products, but has not formally documented where this data resides. A second
data initiative for utilities is cyber security - business-critical data (Operational, Financial, Enterprise
Resource Planning, and Human Resource) must be protected from unauthorized change or transmittal.
Data is both an organizations greatest source of value and its greatest source of risk. Poor data
management often leads to bad business results and to greater exposure to compliance violations and
data theft. To mitigate this risk, many companies attempt to strike a balance between easy data access
and appropriate data use by using mandates (rules, policies and regulations). However, the business
imperative to provide better customer service by quickly using trusted data can cause some to pay
short shrift to these mandates. Similarly, effective use of disparate information can enhance innovation,
but overly strict data security could make such innovative data correlations impossible. An appropriate
balance among data access, data quality and cyber security must be struck by each utility.
Organizations must also consider the business value of their unstructured data. Often referred to as
content, this data needs governance similar to structured data. An example is the creation of a
company-wide records management program. Many firms must retain electronic and paper records for
specific time periods. A rigorous records management policy allows records to be produced during a
legal discovery process in a timely and cost-effective manner, in compliance with established retention
schedules for specific document types.
The following are some benefits derived through data governance:
Improve the level of trust the users have in reports

Ensure data consistency across multiple reports from different parts of the organization
Ensure appropriate safeguards over corporate information for auditors and regulators
Improve the level of customer insight to drive innovation and marketing initiatives
Directly impact the three prime factors for any organization: increasing revenue,
lowering costs and reducing risk
Enterprise Information Management

According to Gartner (White, Comport, & Schlier, 2005), Enterprise Information Management (EIM):
1. represents an organizational commitment to structure,
2. secures and improves the accuracy and integrity of information assets to solve semantic
inconsistencies across all boundaries, and
3. support the technical, operational and business objectives within the organization's enterprise
architecture strategy

Appendix 30
EIM encompasses not only traditional ICT systems, but all systems and devices for which the
enterprise is responsible. Applied to a utility, grid management information is therefore considered
within scope. Accordingly, a utility EIM encompasses information flowing to/from grid edge devices
(distributed energy resources, plug-in electric vehicles, premises area networks, etc.). This ambitious
scope is facilitated by the utility industry use of consistent models (IEC 61850, 61968, and 61970 series).
During the early stages of Smart Grid system of system implementations, traditional utility data
acquisition and control systems (for substations, feeders, and meter head-end) will manage edge device
information. These systems use a mix of proprietary and industry standard protocols (DNP3) to bring
telemetry to a server tasked to make the data available to other enterprise systems. In these cases, EIM
will interact with edge device information representations, not the edge devices themselves. Over time,
as more intelligence is pushed toward the grid edges, EIM will need to simultaneously extend further
into the network. While physical implementations will necessarily vary considerably (due to hardware,
media and computational capabilities functioning within security constraints), the data management
service categories described in this section are expected to extend to all service enabled applications
and devices in any utility Smart Grid system of systems.
A commitment to EIM recognizes enterprise information is as important as process (application
development) and infrastructure (technology). EIM enables raw data to be turned into information,
intelligence, knowledge, and wisdom. As information systems become increasingly vital to business
success, information management must be addressed holistically. In summary, EIM:
Enables utilities to take ownership, responsibility and accountability for the improvement of
data quality, information accuracy and consistency.
Enables utilities to establish single version of truth for data over time.
Improves utilities process and operational efficiency and effectiveness.
Provides a strategy and technique to mitigate the risks as well as maximize the value of
implementing commercial packaged applications.
Reduces the number and size of data integration efforts over time.
Enables the control of wasteful data duplication and proliferation.
Enables process integrations to be more flexible and scalable.
Improves data quality, integrity, consistency, availability, and accessibility.
Maximizes the return on SOA technology investments.
Establishes a critical component of the utility Enterprise Architecture.
Provides guidance and services to information management efforts.
Enables consistent implementations of SOA and information management for major programs.

Appendix 31
Enterprise Information Management Strategy

EIM frameworks [Figure 34] and strategies provide a roadmap to help utilities establish necessary
information governance and technology solutions. EIM can also drive and enable the convergence of
operational, communications and information technologies, key to a utility Smart Grid realization.
Enterprise Vision &
Strategy
Enterprise
Architecture
Enterprise Business
& IT Core
Processes
Enterprise Business
& IT Organizations
Enterprise
Infrastructure
EIM Vision &

Strategy
EIM Governance
EIM Core
Processes
EIM Organization
EIM Infrastructure
Data Quality
Vision
Sponsorship
CSFs & KPIs

Data Integrity
Mission
Stewardship
Data Security &

Protection
Data Lifecycle
Management
Strategy
Goals &
Objectives
Value
Propositions
Policies,
Principles &
Tenets
Data Movement
Alignment
Database
Management
Structure
(Virtual,
Hybrid)
Roles &
Responsibilities
Semantics
Management
Functional
Services
Master Data
Management
Structure
Information
Services
Services &
Support
Business Value
and Relationship
Management
Information
Architecture
Blueprint
Management
Technologies
(DBMS, Content
Mgmt, ETL, EAI,
EII, Data
Modeling, BI/DW,
Collaboration..)
Knowledgebase
and Repositories
Standards & Best

Practices
Figure 34 - EIM Framework
Since much public domain content describes aspects of EIM, the remainder of this section focuses on
how semantic consistency can be improved by leveraging an Enterprise Semantic Model (ESM). The
ESM provides the logical representation of enterprise information assets used to manage or facilitate
business processes. Establishing EIM without an ESM life-cycle design provides little return on
investment since it greatly lessens opportunities for the effective reuse of project artifacts.
Systematic use of ESM supports the following attributes, collectively difficult to achieve otherwise:
Enterprise Information Driven The ESM should utilize internal models, metadata, and
terminology already in use in the utility enterprise. Existing models and common vernacular,
whether or not they are documented, are important sources for ESM development.

Appendix 32
Enterprise Owned the utility owns the ESM, including its terminology, semantics, and
implementation. The utility decides if and when externally controlled semantics are introduced.
Stable The ESM must be stable, keeping established semantics clear and unambiguous.
Non-Static ESMs are non-static in nature, allowing semantics to evolve toward greater clarity
as existing business information evolves or new information is introduced.
Openly Accessible The ESM must provide open access to business-critical information about
semantics, data restrictions, entity refinement, and specific business constraints.
Semantic Traceability Semantic traceability and lineage are important correlations for internal
information (non-ESM semantics).
Industry Standards Aware A robust ESM provides mechanisms to systematically allow input
from applicable industry standard models (CIM, data types, and code lists) to incorporate
standard and broadly-adopted semantics.
Multiple Standards Capable An ESM must be capable of incorporating multiple external
reference models, even allowing for referencing more than one standard from a single business
entity.
Concise Enterprise Semantics By benefiting from both internal sources and available industry
standards, an ESM provides concise enterprise semantics appropriate for business information
across the enterprise.
Business Context Capable - The ESM must support data exchange and information sharing
within a particular business context.
Leverage Available Methodologies - When appropriate, any existing modeling methodologies
should be used in order to avoid reinvention or introduction of proprietary concepts.
Proprietary methods limit choices of service providers, which indirectly will drive up
maintenance and enhancement costs.

All Smart Grid domains require Data Management (DM) services, and most require more capability
than they have today. The increase in data volume, combined with tightening timing requirements,
will cause most Smart Grid enterprises to evaluate their legacy services for future suitability. Data
services can be broken down into data acquisition, transformation, persistence and archiving. A list of
data services and related functions and definitions may be found at <insert url> .
Control Services
Control for electric utilities covers a considerable span of activities. All relate to the operation of control
devices for power flow manipulation, but the scope ranges from consumer basic voltage regulation to
grid interchange scheduling. This sections focus is on transmission and distribution control.
Types of Control
Grid control is decomposed into three major categories, each with unique requirements.

Appendix 33
Transmission and Substation (System) Control

Transmission and substation level control involves control of transmission systems and substations.
The primary elements are:
Power flow control of switchgear defining the power flow paths
Balance dispatch of generation to meet forecasted load, usually by continually driving a
calculated error value toward zero. In the past this was viewed as generation control, but with
the rise of Distributed Energy Resources (DER) and Demand Response (DR), balance authorities
will also dispatch at the distribution and retail levels.
Stabilization control of ancillary services and devices such as generation and Flexible AC
Transmission Systems (FACTS) to maintain rotor angle stability, voltage stability, and frequency
stability; increasingly this includes control of new devices (e.g. flywheel storage) and dispatch of
hydro power to compensate for the effects of some DERs (i.e. solar, wind). This also includes
using FACTS and Phasor Measurement Units to dampen modal power oscillations.
Volt/VAR regulation at the transmission level. This can involve Static VAR Compensators and
other FACTS devices, as well as shunt capacitors at the substation
Distribution Level
Distribution level control has expanded from simple SCADA-based control to advanced distribution
automation, increasingly becoming more complex as the distribution grid becomes the focus for DER
integration. Distribution level controls include:
Volt-VAR regulation regulation of voltage levels and reactive power flow control (and power
factor) at the distribution feeder level. This involves load tap changes, voltage regulators, and
control of capacitor banks. Control of DER-based DC-AC inverters to provide VAR regulation
will also grow in importance as the grid evolves.
Power flow control operation of switchgear and sectionalizing devices to control power flow
at the distribution feeder level
Stabilization control of devices at the distribution level, including use of distribution
STATCOM in addition to more traditional distribution automation
Secondary Load Control

Some forms of secondary load control (load shed for demand side management) have existed for
decades. However, recent requirements have emerged to support DR through the distribution-level
control of ancillary devices. Managing secondary loads with distribution-level controls presents
potentially thorny issues for utility control services and processes. Generally, this means non-utility
control devices residing on customer premises are to be commanded by the utility or a third party (e.g.
aggregator). The requirements on utility control processes are largely dependent on how well the
DR/DER controls are integrated with the utility control systems. Full integration will necessitate close
collaboration between the utility and its customers, probably governed by a formal agreement between
the parties. Little or no integration will reduce the potential of secondary load DR for reducing the level
of expensive daily peak power reserves the utility must provide. The extent of secondary load control

Appendix 34
will likely be driven by economic incentives, which likely means the level of secondary load integration
will gradually grow over time from a small starting point.
Control Data Classes

Several classes of data are important to control systems. The Smart Grid Architect must consider how
to deliver each class to the appropriate destinations within the specified latency. The data classes are:
Telemetry most grid state measurement data (voltages, currents, real and reactive power) are
in the form of telemetry, instrument data produced and collected on a regular basis. In some
designs, sensor data is sent to the control system only upon significant change (i.e. RBE - report
by exception), thus reducing average bandwidth requirements.
Events asynchronous event messages are generated by a myriad of grid devices, many of
which require control actions to be taken. Therefore the control services architecture must
support receipt and processing of such messages. RBE data can be viewed as event messaging.
Forecasts utility control processes make extensive use of various kinds of forecasts - load
forecasts, weather forecasts, and solar/wind generation forecasts being prime examples.
System models utility control processes use system models extensively and the dependence on
such models is increasing in the Smart Grid environment. Two major types of system models
used in grid control processes are:
o
Power state also known as grid state, the power state represents the instantaneous
values of voltages, currents, and real and reactive power flows.
o
Topology power grids have connectivity and the models that represent the circuit and
substation connectivity are crucial context for grid control processes.
Grid state is a powerful concept used extensively at the transmission level, where grid state estimation
is a standard process used in system control. However, it has not been used as much at the distribution
level. The main reasons for this are:
1. Distribution level connectivity models are complex and relatively inaccurate, and
2. Distribution circuits are treated as unbalanced, making grid state estimation costly
As distribution grid observability increases, it becomes feasible to replace grid state estimation with
grid state determination. This combines direct grid state measurement with a minimal amount of
estimation. The availability of distribution grid state is a key factor in enabling sophisticated
distribution level control processes.
Control Properties and Issues

Multi-Objective/Multi-Controller systems as control processes become more complex in a
Smart Grid environment, it becomes desirable or necessary to operate specific grid devices for
multiple business purposes. This need raises architectural issues as to how potentially
conflicting control commands are resolved. Several design patterns for multi-controller
structures are shown in Figure 35.

Appendix 35
Figure 35 - Multi-Controller / Multi-Objective Design Patterns (van Breeman, 2001)
Federation multiple control sub-systems must co-exist in a Smart Grid environment, especially
at the distribution level. Some control systems, as mentioned above, may not reside inside of the
utility, but their grid effect can impact the utility. The federation of multiple, interacting control
sub-systems or processes presents architectural issues unknown in siloed systems.
Disaggregation as more controllable devices are installed at the distribution level, high-level
control commands will increasingly be decomposed to better fit control actions to specific

Appendix 36
conditions on individual circuits or circuit sections. This disaggregation process is a key element
the Smart Grid control services architecture must support.
Context and representation as mentioned above, the context for control actions (and analytics)
is tied directly to the physical connectivity of the relevant grid segment. Consequently, the
representation of grid structure and related information (grid state) are key issues for grid
control services. The Common Information Model (IEC, 2003) schema is a core standard for such
representation and is therefore crucial to the control services architecture.
Control architecture considerations

A number of factors affect control services architecture. Key is the utilitys long-term transition strategy
on how to accommodate legacy control systems while integrating new Smart Grid control capabilities.
Present utility control systems tend to exist in the form of siloed, tightly-bundled systems. Some
examples are Energy Management Systems, SCADA, Distribution Automation, Outage Management
Systems, and the presently evolving Distribution Automation Systems. A traditional control center
functional architecture is shown in Figure 36 below.
Figure 36 - Control Center Functional Architecture (IEC, 2005)

Appendix 37
A transition to a layered, services-oriented system of systems architecture will cause these systems to
evolve away from their siloed and monolithic current state. At present, interoperability efforts are
helping to better integrate these systems, but modifying these products to a full services-oriented
model will be a longer transition. It will probably pace the evolution of the entire Smart Grid. In the
meantime, the system-of-systems philosophy can help the Smart Grid Architect develop large-scale
control services architecture by integrating available control system elements (listed above).
Utility control systems must deal with a range of latency requirements, and as the Smart Grid becomes
more capable, the latencies are expected to decrease. SCADA cycles previously measured in seconds
are being displaced by closed loop stabilization controls operating on the time scale of two cycles (1/30th
second). Some processes will continue to have relatively long latencies, but application requirements
driving control services architecture hardest will be the ones with the tightest time limitations.
The Smart Grid concept includes many more control points than the traditional grid, especially at the
edges (distribution level). As controllable points are added, control architecture scalability becomes
an increasingly important issue. Not only are more points being controlled, but the number of data
points used to compute the control will grow dramatically.
While control systems are vital to smart grid success, the power reliability and availability provided by
the current control services remain of highest importance to power delivery. The smart grid migration
plan must never degrade existing core grid attributes. Grid control services architecture must therefore
have enough flexibility to ensure grid reliability is unaffected as new control features are implemented.
The smart grid environment will involve increasing numbers of control devices as well as processes
and applications. Management of the devices and applications will be complex. The control services
architecture must closely integrate with the management services architecture to provide a unified
approach toward managing settings, protection curves, code versions, exception events, etc.
Control Architectures
Where legacy utility control system architectures were centralized (e.g. EMS, SCADA, OMS), many
future smart grid control systems will be fully distributed or have distributed components. A few
utility control systems are already distributed an example is a fault isolation system using peer-topeer radio and pre-programmed logic on the sectionalizers to isolate faults in distribution circuits. The
smart grid architect should expect control services architecture to transition from mostly centralized, to
partially-centralized, to a final hybrid centralized/distributed state. There are various hierarchical
alternatives for how to arrange the hybrid controls service. An example design pattern for hierarchical
control architecture is shown in Figure 37 below. Such structures will raise implementation issues

Appendix 38
while the utility begins to move away from the mostly centralized legacy control. Managing the hybrid
control services architecture is expected to be complex and time-intensive.
Figure 37 - Hierarchical Control Design Pattern
Conclusion
The control services architecture presents many challenges to the smart grid architect, especially the
coordination of control services with other smart grid services architectures. The challenge is similar to
that posed by the switchover from manual meter reading to AMI any portion of the system is crucial
to operations, cash flow, and customer satisfaction, leaving little or no margin for experimentation or
error.
Security Services
Grid systems security has largely relied upon obscure proprietary protocols and lack of remote
communications access (security by obscurity) to protect grid control devices. The smart grid is
expected to provide a more secure and reliable grid infrastructure.
Security Threats
Smart Grid Cyber Security concerns dictate a multi-faceted approach to security. The system must
provide security controls to address concerns unique to the implementation environment, and to
interactions and interdependencies with other enterprise and business applications. The smart grid
security architecture must address these concerns with a rich set of controls designed to facilitate
tailored and highly granular supervision. Each control must be engineered for its environment,

Appendix 39
mission, and user. The resulting solution must manage the full lifecycle security for every aspect of
information and technology, from edge to back office devices and from engineering to implementation.
Physical Security Threats

Utilities need to respond to increased physical threats on their electrical assets with a greater number of
physical security systems (e.g. video surveillance, biometric-based access controls, alarms, motion
detection sensors, etc.), as well as other measures. Physical threat counter-measures demand
coordination, management, and communication infrastructure to relay information to appropriate
Security Control Centers and Emergency Centers (i.e. the Police, Fire Department and local Hospitals).
Training must also be provided to utility personnel on a regular basis to ensure a high-level of security
awareness in each employee. Each person needs to know how to identify potential physical threats and
how to contact the appropriate resource to mitigate the potential risk.
Cyber Security Threats

The increased use of Information and Communications Technologies (ICT) in the smart grid also brings
additional security threats potentially impacting electric power system reliability. Sophisticated cyberattacks could devastate this infrastructure, and the dependent economy. Cyber security threats have a
broad sweep, from relatively minor (an attempt to bypass a meter), serious (an organized crime
attempt to extort utility funds by threatening service disruptions), to existential (national adversaries
seeking to destabilize the countrys critical infrastructure). Other potential threats include intentional
attacks by disgruntled employees or unintentional errors made by well-meaning employees.
Considering the millions of electronic devices (e.g. smart meters) being deployed with expected
lifetimes exceeding 15 - 20 years means applying ex post facto security can no longer be tolerated. Smart
grid systems must be secure by design.
Using Internet Protocol (IP) for smart grid communications and open standard protocols for grid
control necessitates securing the grid at multiple points. The Smart Grid Security Services provides
security enforcement at these points (e.g. SCADA Network systems, the Utility Communication Link,
Advanced Metering Infrastructure, Substation Remote Monitoring Equipment, and Meters to MeterData Collection Points).
In addition, utilities may need to enhance the protection applied to their public-facing portals (i.e. web
pages). These will inevitably be attacked as Demand Response prosumer energy controls are activated
by smart grid projects. Security architects will need to defend against these cyber-attacks while
protecting sensitive customer data without disrupting any prosumer using utility internet tools
provided to help manage electricity.

Appendix 40
This security perimeter expansion has both topological and identity-based elements. This allows
Security architects to classify and prioritize security vulnerabilities for each communication
infrastructure perimeter, as illustrated below by Figure 38:
Figure 38 - Security Threats Classification
With all the potential security threats to the smart grid, how can a Security architect ensure grid
security and reliability? Simply complying with regulatory requirements is usually not sufficient to
protect critical systems against determined adversaries. Security architecture must be pervasive. It
requires considerable planning, analysis and design concurrent with other grid architecture designs.
Security Assessment
In order to address the diverse grid threats, the security architecture must perform an assessment to
identify ICT security vulnerabilities and risks. To be successful, all utility business units and support
organizations must participate, allowing access to their ICT infrastructure and providing the
transparency needed to uncover all known and potential security attack vectors.
Each security assessment must also consider evolving legal and regulatory security requirements. This
helps the utility remain compliant with external mandates (i.e. NERC CIP, NISTIR, NIST 800-xx,
various state and local directives).
The Security Architect must clearly communicate the objectives of each assessment:
Review existing security policies and identify potential gaps to reduce organizational risk
Ensure necessary security controls are integrated into each projects design
Provide documentation outlining any security vulnerabilities and suggest solutions
The following methodology outline is an effective means to conduct a security assessment:


Appendix 41
Requirement Study and Situation Analysis

Document Review
Risk Identification
Vulnerability Scan
Data Analysis
Report & Briefing
As noted above, the Security Assessment identifies security vulnerabilities. It also helps define the
security strategy for the smart grid system-of-systems. The huge number of interconnected points in
smart grid makes its security very challenging. The Security Assessment helps the utility determine the
assets to security-enhance and those with an acceptable risk level. The Levels of Criticality and Levels
of Trust, described later in this section, are relevant tools for this assessment.
The Smart Grid Cyber Security concerns dictate a multi-faceted approach to security. The system must
provide security controls to address concerns unique to the implementation environment and
interdependencies among enterprise and business applications. The smart grid security architecture
must address these concerns with a rich set of controls designed to facilitate tailored supervision with a
high degree of granularity. Each control must be engineered for its environment, mission, and user.
The resulting solution will manage security from cradle to grave for every aspect of information and
technology, from edge devices to Back Office; from engineer to implementation.
The imperative to address emergent cyber security concerns as the smart grid matures requires a Risk
Adaptive Architecture. This architecture combines risk management and principled systems
engineering methods to produce a scalable, modular solution. This equips security architects with tools
needed to respond as threats, technology, regulation, and usage independently change.
The Security Architect must also study technology providing direct security capabilities, as well as
functionality to simply enable secure policy, architecture, and configuration. The security architecture
should use the best cryptography along with filtering, firewalls, segmentation, and virtualization.
Physical security must be interwoven with cyber security to ensure controls are appropriate, effective,
economical, and enduring. Finally, recognizing even the best of systems fail and no armor is perfect,
the security architecture must develop a holistic approach to deter, prevent, detect, react, and recover.
Security Context
Central to the notion of security services for risk adaptive security architecture are the related concepts
of security domains and levels of trust. The two broad smart grid service domains are described below.
The trust level is derived from data quality and source trustworthiness.
Since smart grid spans a complex trust environment, it must be capable of distinguishing, labeling, and
segmenting data based on its origin and the systems level of confidence in the data. Smart grid

Appendix 42
functionality must have enough resilience to ensure essential functions remain available should data
sources be suddenly deemed untrustworthy and dropped from analytics, displays, etc.
Security Service Domains

A security service domain is an area with a relatively consistent set of constraints and expectations.
There are two security service domains:
The Centralized Security Services domain drives the security scheme, providing automated
security services to all elements of the system as well as management capability for each of the
automated services.
The Decentralized or Edge Security Services domain provides the field component counterparts
for relevant services in the Central Security Services domain. Both domains leverage physical
access controls to compliment electronic controls in creating a complete protection picture.
Levels of Criticality
NERC currently defines three levels of criticality when it comes to CIP: High, Medium, and Low:
Bulk Electric System (BES) Subsystems have High Impact if, when destroyed, degraded or
otherwise rendered unavailable, they could directly cause, contribute or create an unacceptable
risk of BES instability, separation or a cascading sequence of failures.
BES has Medium Impact, if, when destroyed, degraded or otherwise rendered unavailable, they
could directly affect the electrical state or the capability of the BES, directly affect the ability to
effectively monitor and control the BES.
BES has Low Impact if, when destroyed, degraded or otherwise rendered unavailable, they
could not directly cause, contribute to, or create an unacceptable risk of BES instability,
separation, or a cascading sequence of failures.
Levels of Trust
The level of trust for a particular datum starts with an assessment provided by the data source and
retained in the data headers quality field. The system combines this value with a measure of the trust
assigned to its source to define the data level of trust as one of the following:
Trusted: The data meets all predetermined criteria and is displayed and/or incorporated
normally. The operator retains the ability to manually override the decision.
Questionable: The data meets some but not all criteria or falls within a designated window
whereupon the system warns the operator of the condition and prompts for data inclusion.
Untrusted: The data fails to meet predetermined criteria and is not displayed or incorporated in
calculations. The operator retains the ability to manually override the decision, however the
system will indicate it is in an override condition.

Appendix 43
NISTIR 7826 Security Guidelines (NIST-ITL, 2010)

In August 2010, the NIST Information Technology Laboratory (ITL) issued a three-volume NIST
Interagency Report (NISTIR 7628) entitled Guidelines for Smart Grid Cyber Security (NIST-ITL, 2010) to
discuss ITLs research, guidance, and outreach efforts in computer security and its collaborative
activities with industry, government, and academic organizations. A month later, the Smart Grid
Interoperability Panel (SGIP) Cyber Security Working Group published the Introduction to NISTIR 7628.
The following text is from a sidebar on page 3 of this introduction, At a Glance: Report Objectives:
The transformation of todays electricity system into a Smart Grid is both revolutionary and
evolutionary. Persistence, diligence, and, most important, sustained public and private
partnerships will be required to progress from todays one-way, electromechanical power grid
to a far more efficient digitized system of systems that is flexible in operations, responsive to
consumers, and capable of integrating diverse energy resources and emerging technologies.
This progression will unfold over the span of many years, during which several generations of
technologies will compose the evolving Smart Grid. As a consequence, the cyber security
strategy for the Smart Grid must also be a continuing work in progress so that new or changing
requirements are anticipated and addressed.
Guidelines for Smart Grid Cyber Security is both a starting point and a foundation. As Smart
Grid technology progresses, the Cyber Security Working Group (CSWG) will continue to
provide additional guidance as needed. This first installment of the guidelines is:
An overview of the cyber security strategy used by the CSWG to develop the high-level
cyber security Smart Grid requirements;
A tool for organizations that are researching, designing, developing, implementing, and
integrating Smart Grid technologies established and emerging;
An evaluative framework for assessing risks to Smart Grid components and systems during
design, implementation, operation, and maintenance; and
A guide to assist organizations as they craft a Smart Grid cyber security strategy that
includes requirements to mitigate risks and privacy issues pertaining to Smart Grid
customers and uses of their data.
The guidelines are not prescriptive, nor mandatory. Rather, they are advisory, intended to
facilitate each organizations efforts to develop a cyber security strategy effectively focused on
prevention, detection, response, and recovery.

Appendix 44
NISTIR 7628 should be studied closely by all smart grid security architects. The three volume report
contains a myriad of methods and related information designed to help organizations assess risk and
then to apply appropriate security requirements to mitigate the risks identified.
Communication Services
Communication services (comms) are fundamental to electric grid operations. They enable devices to
be intelligent, information to flow, controls to execute, and people to manage utility functions and
services. Large numbers of new smart devices will be deployed in a smarter grid, each needing some
form of communications. Planning for this deployment is difficult since most devices dont yet exist
and initial functionalities will change as grid operators figure out innovative ways to leverage their
intelligence. Thus, it is critical for the future grid communication architecture to be extraordinarily
resilient and flexible.
It is strategic to develop a clear understanding at the conceptual layer of the interplay between smart
grid objects (endpoints), the information they communicate, and the channels across which that
information flows. This will provide context for rationalizing the communication functions at the
services layer.
Figure 39 - Conceptual and Services Layers
Every endpoint, all information types, and each communications channel are different. Their
combinations are staggering and their capabilities continually change. The comms requirements to
support smart grid use cases are proof of this diversity (see Table 25 Communications Services). This

Appendix 45
will remain true as new smart grid use cases emerge. Characterizing these requirements can be
extremely challenging. For example, performance requirements can range from exceptionally stringent
to relatively modest. Information flows could be streamed, polled, infrequent, message mode, file
transfer mode, or asynchronous event-driven. Application architectures can vary from highly
centralized, to distributed, and some could even be peer-to-peer. The quantity of actors in these use
cases could range from dozens to millions. Most are stationary, but others require mobility. Some are
critical to grid operation while others are of marginal operational importance. This diversity challenges
the enterprise architect to devise flexible, scalable smart grid communications architecture.
The Nature of Smart Grid Endpoints, Information and Channels

A framework around which communication services might be considered should examine the nature
of: (1) the actors (endpoints and their functional requirements), (2) smart grid information, and (3) the
channels through which information will flow. Thoroughly understanding these drivers will help the
smart grid architect put the supporting communication services in a proper context.
Smart Grid Endpoints

Grid endpoints include a range of devices. In general, they include field devices such as meters,
reclosers, capacitor banks, and so on. There are a variety of devices in substations including IEDs,
SCADA RTUs, teleprotection devices, measurement devices, security appliances, and so on. At data
and operations centers there are head-end processors, data collection units, control systems, customer
interface portals, etc.. In general, these endpoints provide the smart grid application functions. For
purposes of this reference architecture, the communication nodes are not considered endpoints since
they dont provide application functions.
Each of these endpoints has unique operating capabilities. The smart grid architect should consider a
variety of aspects of these endpoints when planning comms solutions including:
Diversity of purpose Will the endpoint support a single purpose or is it a multipurpose
device? For example, meters are typically thought of as devices providing usage data. But in
smart grid, meter functions expand to include usage, remote connect/disconnect, outage alerting,
and power quality data. Metering groups need the usage data but grid operations teams would
be interested in outage and power quality data. How does this impact comms architecture? As
an example, if a meter is placed in a virtual network designed for metering, then additional
challenges need to be considered in the overall architecture in regards to security, performance,
and operations in order to direct outage and performance data to the appropriate recipients.
Diversity in scope Will the endpoint communicate to just one (or redundant) other endpoint
or will it communicate with a diverse set of other endpoints? Extending the example of
metering, it may be necessary to regularly collect usage data from a centrally located meter
collection engine. Outage information could be captured by distributed OMS pre-processors
located at substations so event messages don't congest the backhaul networks. Power quality

Appendix 46
data may need to be periodically collected by analytics systems. In this example, meter
endpoints may communicate with three or more host system, each existing in different domains
and at different locations. However, teleprotection devices may not have the same multi-domain
requirement. For operational reasons it may also be necessary to restrict the devices able to send
traffic to the teleprotection equipment.
Criticality Is the purpose of the endpoint to support: a critical real-time function, for billing or
analytics purposes, or for informational but non-critical functions? Some devices are seen as
more critical than others for a variety of reasons. For example, if a teleprotection device fails to
operate in a timely manner it could result in the loss of electrical service to thousands of
customers which could extend for weeks. Associated damage to grid equipment could cost
many hundreds of thousands of dollars. Therefore communication solutions for teleprotection
devices warrant significantly more investment for reliability and resiliency than communication
solutions for a feeder-capacitor bank with a potential to affect far fewer customers if information
cannot flow in a timely manner.
Mobility Is the device mobile, fixed, or transitional? Most smart grid devices do not need
mobility protocol support since they will be mounted on homes, poles or in building facilities.
However, there is increasing need to support mobile workers and mobile machine-to-machine
solutions. Mobility introduces many architectural challenges (coverage, access methodology,
roaming support, location awareness, etc.).
Quantity How many devices will exist in a mature implementation? How will their numbers
be spread across the various communication domains? How will management systems support
potentially millions of devices such as meters? What are the impacts to traffic capacities and
congestion control?
Geographic density Where will devices be deployed? For the various kinds of devices, will
they be widely dispersed, densely placed, adjacent or in close proximity to other grid devices?
How does this impact communication media choice? Can proximity be leveraged or does it
present challenges (interference, signal power constraints, etc.)?
Degree of intelligence How intelligent is the endpoint? Is it highly dependent on other
systems for resources and functionality? If so, where do they exist and what is their criticality to
other endpoints? Where does the application intelligence for this endpoint exist? Most legacy
grid systems use centralized intelligence; therefore centralized communication architectures can
support them (very common for SCADA and AMI systems). However, if intelligence becomes
distributed, then the communications architecture must also be distributed. For example, if grid
intelligence is distributed to the substation, could field-mounted devices effectively
communicate to the substation?
Smart Grid Information

The information transmitted between smart grid endpoints varies widely. It comes in many forms,
sizes, criticality, and regularity. For a variety of reasons, not all communication systems are conducive
for handling the breadth of requirements from required smart grid information sources:
Regularity of transferring information Will information be a continuous stream, scheduled
transactional, or event-driven? This issue concerns how to think about congestion management.
Streaming information (like PMU data) and scheduled transactions (like AMI reads) are

Appendix 47
predictable and easier to plan for. But event-driven information can be very challenging.
Furthermore, how does information regularity impact communication session management and
security mechanisms (for example key management, access control, and authentication)?
Size What is the size of the information? This issue concerns how to think about bandwidth
requirements. Is it streaming and as such is continuous? Is it a predictable file size? Is it messageoriented and contained in predictable bytes or even bits?
Form Is the information structured (XML file), bit-oriented (on/off), or byte-oriented (DNP3,
IEC) defined messages? Is the information unstructured (such as a continual tone)?
Duration/longevity Is the information archivable (meter and other forms of measurement),
transactional with a short time-to-live (outage or state data), or potentially a repeatable
transaction (control data with message acknowledgement)? How does this impact
communication system choice and failover schemas?
Criticality Is the information critical, not critical, or somewhere in between? Does it warrant
high availability or redundancy? If so, to what degree of reliability should the system be
designed (is 99.999% reliability necessary or would marginally lower reliability suffice)? How
does information criticality impact the failover schema at the application layer versus at the
communication layer?
Simulcast Will information be broadcast for any interested device to receive (publishsubscribe systems), multicast to a defined set of multiple devices, or unicast to just one device?
Broadcast and multicast information can challenge the communications solution.
Ownership Who owns the information? What policies govern access to the information? What
are the implications at the application layer versus the communications layer?
Diversity of usefulness Is the information useful across multiple applications? Example: some
AMI transactions combine usage and power quality information.
Smart Grid Channels

There are a wide variety of channels (media) over which smart grid information might travel. Most of
the time, information will travel over a network of networkseach optimized for some collective need.
Understanding why different networks are necessary and how they function is critical to achieve
optimal communications architecture.
Access mechanisms How is the channel accessed? This issue is especially of concern for
wireless systems where media sharing can be challenging. Some solutions use network-based
synchronized time slots (polling) schemes to limit collisions but this can affect performance.
Other solutions might use application layer polling that, if combined with network-based
polling, could be unnecessarily redundant.
Shared use If the channel is shared, how will traffic utilization be handled? For example,
expensive wide area networks will likely need to support high priority critical traffic and lower
priority informational traffic. How will traffic priorities be administered? What happens if
devices that share the same channel (meters for example) cannot effectively hear one another?
Do data link layer capabilities exist to prevent genuine information from appearing as noise?
Distance between devices Does the distance between devices warrant powerful transmission
signal levels (many miles)? If so, how would it affect system cost structure? Is the distance short
enough to allow communications capabilities at one device to support other nearby devices?

Appendix 48
Diversity of function Will channel use support a variety of applications with varying
performance and security needs, or will the channel be purpose-built for a particular solution?
Performance What are the latency capabilities of the channel? Some media (fiber optics) can
support extraordinary performance characteristics. However, due to contention and framing
mechanisms, wireless systems generally support more moderate characteristics and their
effective performance range can vary widely.
Bandwidth What is the bandwidth of the channel? Different media types support varying
amounts. At the low end, some long-reach wireless systems might only support 10s of kilobytes
per second. At the upper end, some fiber solutions can support many gigabytes per second.
Reliability What reliability schemes are used on the channel? There is a wide spectrum of
reliability mechanisms a communications system could deploy. Cost considerations must be
applied to obtain the necessary degree of reliability and performance these schemes can deliver.
For example, do applications on field area networks warrant 99.999% reliability? What is the cost
for the desired reliability? Is a 50 millisecond failover scheme on a Synchronous Optical
Network (SONET) based teleprotection circuit acceptable to application users? What would
happen if the failover detection was only a few milliseconds but the reconvergence time for
information flow measured in the hundreds of milliseconds?
Media cost structure What is the cost structure of the media? When it comes to
communications, the balance between cost and performance must always be considered. Some
wireless solutions may not require much channel costs (i.e. free space propagation, licenseexempt systems, and very limited path engineering). However other wireless solutions might
require licensing and very diligent system engineering. Furthermore, fiber placement might
require public right-of-way and construction costs. Costs must be reasonable for the set of
applications supported by the media. For example, under what circumstances would fiber
deployment be warranted for meter communications?
Equipment cost structure What is the cost structure of the equipment? Communication
systems have a wide spectrum of features and capabilities (power consumption, interface
redundancy, management, etc.). The architect must determine what is reasonable for the
environment and the applications being addressed. While many capabilities are generally
desirable, if unchecked they may encumber the solution cost structure. For example, is it rational
to deploy communication devices with no power supply or interface redundancy at
transmission substations?
Environment What is the nature of the channel environment? Does it require special
hardening? Is the equipment location under the direct and exclusive control of the utility?
Administration How will the channel be administered? Will the channel be under the
management and administration of the utility or will the utility obtain channel services from a
provider? How will channel administration affect service assurance and restoration? How will
periodic changes on communication system(s) be coordinated with utility business operations?
Understanding the conceptual layer of endpoints, information and channels helps frame the
communication services necessary to support smart grid operation. Once identified, the

Appendix 49
communication services can be mapped to the various network of networks comprising the overall
communications architecture.
The Communication Services layer [Figure 40] requires the following functions:
Transport services to move information around the network,
Virtualization services to help segregate and optimize transport services,
Control services to help manage information flow and support endpoints needing network access,
Gateway services to facilitate legacy applications to utilize next generation networks, and
Mobility services to support roaming or mobile endpoints.
Figure 40 - Communication Services Layer Functions
Transport Services
Transport services are the means to move information around the network. Transport services are
derived when communication links are combined to form networks. Since smart grids can cover a wide
expanse of territory, a network of networks must be developed and interconnected so endpoints can
send and receive information across the networks transport services.
When considering transport services for smart grid, the smart grid architect will make a series of
choiceseach time providing more and more detail. The highest level choice defines the type of
transport service to deploy. Next, the architect must determine logical divisions for each network
within the network of networks (subnetworks). Only then can the architect establish each
subnetworks operating characteristics. Figure 41 illustrates this process below:

Appendix 50
Figure 41 - Transport Services Consideration Process
1.
Type
First, the architect must make the decision of what type of transport service to deploy. There are two
fundamental types of transport networks: circuit switched and packet switched. In the general world of
telecommunications, it has been long established that packet-based solutions provide the most ideal
form of transport services. The primary value of packet-based solutions comes from their ability to
support an extraordinary array of applications over a common infrastructure. This provides
exceptional economic and operating benefits. Another key value is that packet solutions were a product
from a methodology supporting a layered approach whereby applications could evolve independent of
the network. Abstracting the applications from the network provides both versatility and stability for
each environment. In the case of smart grid where innovation is expected and requirements will be so
diverse, packet-based transport solutions are the only logical choice.
Although virtually all new investments are packet-based, there are still large amounts of legacy
applications and infrastructure that will co-exist for some time. Adapting these systems to packet
transport services is necessary and will be covered below in the Gateway Services section.
2.
Logical Division
The next decision that must be made is the logical division for each subnetwork making up the end-toend solution. Implied is that there isnt a single ideal transport network for accommodating smart grid.
Therefore some form of subnetworking must take place to achieve various transport service capabilities
(described below). For example, some networks are optimized for ultra-high speed but its cost
structure can be burdensome. Since not all applications warrant such costs, networks of lower
capabilities may be needed. The same tradeoff can be made regarding other characteristics such as
performance and security requirements. Network technologies have limits and thus the

Appendix 51
implementation of subnetworks is necessary. For making subnetworking decisions, it is best to

establish functional categorization.
While it is tempting to categorize transport services according to media type (fiber, wireless, powerline
carrier, etc), this leads to ambiguity. For example, the kind of fiber networks used in data centers is
different from fiber systems used to reach extraordinarily long distances across a utilitys operating
territory. And the variety of wireless systems includes solutions such as long-haul microwave,
metropolitan-based WiMAX, local WiFi, and even Zigbee personal area networks.
It is better to categorize transport services into functional subnetworks. It appears this is what NIST has
done in their Smart Grid Conceptual Reference Diagram [Figure 42] as they identify:
Internet / e-Business
Enterprise Bus
Wide Area Networks
Substation LANs
Field Area Networks
Premises Networks
Figure 42 - Conceptual Reference Diagram for Smart Grid Information Networks (NIST, 2010)

Appendix 52
The NIST Conceptual Reference Diagram is a functional categorization, except for the use of the
Operations domain term Enterprise Bus (usually a software-based mechanism for abstracting
applications from transport services) instead of Operations Center LANs. The Internet / e-Business
clouds in Figure 42 suggest communications to external entities such as trading partners, customers,
and other market operators. The Wide Area Networks cloud reflects the communications required
across expansive territories from information processing centers to moderately remote assets
(substations, data concentrators). The Field Area Networks cloud represents connectivity from
various points of concentration out to numerous, scattered, and small endpoints.
Functional categorization of transport systems provides the architect a framework to evaluate
subnetworks and to make business, economic and technical choices. For example, the architect may
initially opt for a carrier-provided public wide area or field area network. As the system evolves certain
critical or highly used links could be replaced with utility-owned infrastructure (fiber or some form of
wireless media). There may be instances where the utility initially operates a wireless solution based on
cost structure but the evolving smart grid eventually causes fiber links to supplant the wireless links.
The functional transport service architecture also helps the architect make the decision when to
converge or segregate subnetworks. For example, the wide area network domain provides connectivity
between Operations or Control Centers and remote substations. From an electric grid standpoint, the
wide area network is generally associated with covering the transmission grid and substations whereas
the field area network covers the distribution grid beyond the substation (Figure 42). Applications and
endpoints associated with the transmission grid require high performance capabilities and warrant the
diversity and higher reliability associated with more costly network solutions. As a media choice, fiber
offers the highest degree of performance and is therefore often preferred in the wide area network.
Since it can be costly to operate multiple wide area networks over the same geographic footprint,
converging traffic onto a single (virtualized) fiber-based wide area network can be advantageous. In
any case, the unique properties for each network domain are important architectural considerations.
3.
Characteristics
After choosing the type of transport service and the logical divisions for subnetworking, the architect
must then make key business, operational, and technical decisions regarding each subnetworks
operating characteristics. Each issue impacts architectural choices just as they influence design choice.
Common domain issues to consider include:
Bandwidth - How much is required and available? How is it consumed and/or allocated? How does
bandwidth utilization impact architecture decision?
Latency and jitter How does the transport service architecture support and manage latency and
jitter? How do protocols used across the transport service impact latency and jitter? How do latency
and jitter influence network element architecture choice?

Appendix 53
Domains How are transport services virtualized into segregated domains to support bandwidth,
latency, privacy, and management? (Also covered in the Virtualization Services section below.)
Resiliency How do the failover mechanisms support the transport services within each of the
subnetworks and from an end-to-end perspective? What are the performance capabilities of the
resiliency mechanisms?
Quality of Service What quality of service capabilities exist for the transport services in each of the
different subnetworks?
Reliability What is the reliability of the transport service at each of the subnetworks?
Access How will devices gain access to the transport service? Will there be many devices
attempting to access the services simultaneously?
Standards What standards apply? Are there functional gaps not covered by standards?
Management How are transport services granted, restricted and controlled?
Costs What is the cost structure for various types of transport services?
Differences among the domains begin to drive further architectural considerations. For each of the
transport service domains, key issues have been identified:
Internet / e-Business
Purpose provide connectivity to customers, suppliers, business partners, emergency services, and
the public at large
Design Issues generally open access to public environments, security, accessible by millions of
users, public infrastructure (carriers), Internet, data/voice/video/control services, performance,
capacity seldom measured beyond a few Megabits, failover to alternative external
networks/providers, infrastructure dependent on carrier preference, global reach
Operational Issues lack of autonomous control, lesser degree of monitoring/management,
dependence on others for reliability and performance, recurring expenditure, service contracts,
capacity driven
Operations Center LANs

Purpose provide connectivity to control systems, operators, high-end applications, servers, and
storage systems
Design Issues extremely tight controlled access, highest degree of security, highest degree of
performance, multi-Gigabit support, high availability designs, thorough virtualization,
data/voice/video/control services, primarily fiber infrastructure, building area reach
Operational Issues key location for grid intelligence, full autonomous control, highest degree of
monitoring/management, highest reliability, highest performance, infrastructure can be capital
intensive, project driven
Wide Area Networks

Purpose provide high performance connectivity (a) between data/control centers, (b) from
data/control centers to key remote facilities such as substations, (c) from data/control centers to
points of data concentration (such as meter data concentrators)

Appendix 54
Design Issues tightly controlled access, high security, high performance, range from tens of
Megabits to multiple Gigabits, situational high reliability, failover mechanisms very responsive,
virtualization and converged resources, data/voice/video/control services, primarily fiber and
microwave, SONET, MPLS, IP, public or private infrastructure, regional geographic reach
Operational Issues -- reach to places where grid logic has been distributed, situational control
(public or private), high degree of monitoring/management, desired interaction between grid and
telecom management systems, high reliability, high performance, capital or expense funding, project
driven
Substation Local Area Network

Purpose provide coverage to smart objects within and near by the substation
Design Issues controlled access, security, high performance commensurate with applications,
range from tens of Megabits to Gigabits, high reliability, failover mechanisms including high
availability, may require segregated overlay solutions for separating process bus traffic from other
traffic, data/voice/control services, primarily fiber and wireless technologies, reach in the immediate
vicinity of the substation
Operational Issues reach to dozens of endpoints which can support other devices through
distributed grid intelligence, total control by utility (private), moderate monitoring/management,
desired interaction between grid and telecom management systems, high reliability, high
performance, capital funding, project driven
Field Area Networks

Purpose provide broad coverage to remote field endpoints so that they can connect to (a)
data/control centers, (b) distributed applications (perhaps at substations), and (c) to other remote
endpoints
Design Issues controlled access, security, moderate performance commensurate with applications,
range from one to tens of Megabits, moderate reliability, failover mechanisms often unavailable,
may require segregated overlay solutions optimized for the applications, data/voice/control services,
primarily wireless and powerline carrier technologies, reach may be similar to that of the serving
substation
Operational Issues reach to thousands or millions of endpoints which have lesser degree of grid
intelligence, situational control (public or private), moderate monitoring/management (desire selfdiscovery and auto-configuration), desired interaction between grid and telecom management
systems, moderate reliability, moderate performance, capital or expense funding, project driven
Premises Networks
Purpose provide coverage to smart objects within the home, business, and commercial enterprise
Design Issues controlled access, moderate security, moderate performance, range from tens of
kilobits to a few Megabits, moderate reliability, seldom use of failover mechanisms, likely
segregated overlay network, data/control services, reach within the customer premises,
predominantly responsibility of customer rather than utility
Operational Issues reach several to many endpoints with emphasis on premises intelligence,
virtually no control since under authority of premises owner, moderate to no

Appendix 55
monitoring/management (desire self-discovery and auto-configuration), largely isolated from grid

management systems, moderate reliability, moderate performance, capital expense by premises
owner, service subscription driven
Network Control-Plane Services

There are many network control-plane services to be accommodated in smart gridtoo numerous to
go into detail in this work. A few control-plane services with smart grid interdependency warrant
discussion. To adequately address future smart grid requirements, the architect must understand
network addressing, name-address resolution, and subnetwork access management.
1.
Network Addressing
The mature smart grid will see a dramatic increase in smart objects needing IP addresses. It is more
strategic to deploy new smart objects using IPv6 (and its addressing) rather than currently dominant
IPv4. Among the many benefits IPv6 offers, the avoidance of Network Address Translation (NAT)
functionality is one of the more critical reasons to adopt IPv6. The use of NAT can be burdensome to
control-based applications. When network anomalies require failover, the NAT function must rebuild
the address translation mapping. This process can burden (or break) time-critical grid applications.
IPv6 addressing can avoid this problemat least for communication within the utility domain
(extranet access could still have this problem if private IPv6 addresses are used).
In the IPv4 era, private IP addressing and NAT were implemented to slow down consumption of the
rapidly depleting pool of IPv4 addresses. In this time of transition, it is recommended that utilities
rapidly move to adopt IPv6. There are several types of IPv6 addresses including: unicast, anycast and
multicast. In addition, IPv6 addressing supports both public and private address spaces.
From an addressing architecture perspective, it is recommended that private IPv6 addresses (called
local unique addresses) be used behind company firewalls as an added security measure against
unintended access to grid devices from outside parties. Careful attention should be given to prevent
reuse of private addresses as this will result in problems tracking SYSLOG issues.
Another addressing architecture consideration involves the use of static or dynamic IPv6 addresses.
Many control functions will rely on static (unchanging) addresses. However, many grid applications
(premises metering) could benefit from dynamic addressing. Part of the architecture development is to
decide where to use dynamic addressing. For non-mobile devices, dynamic DHCPv6 addressing may
be best enabled from the substation or where Field Area Network interfaces backhaul communications.
And finally, address space allocation must be planned with the end-state in mind. As the smart grid
evolves, more devices will be placed into the field. Address space allocation should accommodate the
eventual conversion of remote grid devices (including substation devices, feeder devices, meters, and
perhaps even premises devices) to IPv6 addressable devices.

Appendix 56
2.
Unique local Addresses
Domain Name Services (DNS) will be necessary in the smart grid. DNS permits the abstraction of a
devices IPv6 address from its name making application systems less vulnerable to periodic changes.
While a common DNS solution could serve both the enterprise and operations environments, there are
advantages for segregating these services. Due to the magnitude of most smart grids, the Operations
DNS easily become more heavily populated and used than the enterprise DNS.
One important architectural concern is how to sustain name services at remote locations when
host/remote links are severed. It is preferable to operate DNS in an HA configuration with primary
zone servers in redundant control centers. In the case where backhaul links are lost, name resolution
for regional traffic can be sustained only as long as the Time To Live setting permits. Therefore, for
critical applications, it might become necessary for secondary zone servers to be distributed regionally
in key substations.
3.
Authentication, Authorization and Accounting function
AAA servers are required in the grid to aid with the authentication, authorization and accounting
function of devices connected to the network.
From a communications architecture perspective, it is important to segregate AAA functionality
serving the smart grid from enterprise AAA functionality. It will also be preferable to distribute AAA
functionality operated with primary and secondary systems located at diverse control centers.
In the event of the loss of backhaul connectivity, critical substations could benefit from having local
AAA services. Other substations may lose accessibility except via local console access.
Mobility Services
Support for mobility is required for both smart grid devices (especially inside the FAN) and users (such
as the linemen of the future). The mobility service needs to encompass:
Life cycle management of mobile devices, including registration and provisioning of mobile
devices on to the network, such as configuration through the wireless LAN controller, and
Secure deployment and configuration services, such as forcing the mobile user/device into a DMZ,
enforcing a profile examination etc before given access to the network
Gateway Services
The term gateway can be ambiguous for telecommunications. For this document, it refers to the set of
services used to adapt legacy or otherwise non-conforming endpoints to packet-based transport
services. In doing so, gateways translate traffic from one protocol to another. This presents a challenge
for Smart Grid development for two reasons: complexity increases with each required adaptation and
scalability is constrained due to the limited usefulness of proprietary devices. Although it is preferable
all applications standardize on Ethernet- and IP-based transport services, it is also recognized it will

Appendix 57
take some time for existing/embedded systems using proprietary protocols to be replaced. Therefore
gateway services must be implemented in various parts of the network to adapt those devices.
In the architectural context, gateways bridge the application and network domains. Therefore, when
dealing with gateways, network architects and application architects should address gateway service
concerns. Two key areas of interest include the appropriate location for gateways to reside and the
feature sets they offer.
Some common legacy gateways include the electric meter (bridging traffic into the home), AMI
gateways (supporting ANSI C12.22 traffic across proprietary networks), DNP gateways (often used in
recloser operations and for line sensors), and station managers (adapting legacy traffic in substations to
use packet infrastructures). Very often, legacy systems integrate communication control and transport
functions into the application rather than cleanly abstracting the two. Even though many such
solutions may be standards based (ANSI, DNP, Zigbee, etc), they dont inherently use the standard
transport protocols common to packet (IP) solutions. Therefore the traffic must be adapted.
Although it can be confusing, there are some gateways deployed for smart grid for reasons other
than transport service adaptation. For example, XML gateways are deployed to offload some security
and application layer functions from application systems. These are not considered network layer
gateways. In addition, research and development occurring in the fields of distributed intelligence and
complex event processing will necessitate systems deployment further out in the network.
The first decision the architect must make is where gateways should reside in the smart grid ecosystem.
The time-proven, primary end-to-end principle in IP networking requires application layer issues to
reside at the endpoints and not within the network. Applying this principle to the necessity of smart
grid gateways makes it preferable for gateways to be pushed as far as possible toward the network
edge. Therefore meters would not have to adapt traffic and protocols between home devices and the
utilitys network (in fact Zigbee supporters are adopting the use of IP transport systems eliminating the
need for protocol translation at the meter). AMI gateways would be pushed to the edge of the Field
Area Network. DNP gateways would be collocated with legacy devices, and substation managers
would only serve legacy, non-IP-enabled devices within the substation.
The second area of interest to smart grid architects is the breadth of functionality performed inside
gateways. Some gateway suppliers are embedding more functionality into legacy devices. The result
could be an increased dependence on gateways (rather than a transition to standards-compliant
devices). In addition, it is also tempting to deploy low-level standards-based networking functions
inside gateways rather than derive these functions from true network-layer equipment. Such practices
only deepen the dependence on legacy gateways/protocols and restrict the adoption of open and
standardized architectures.

Appendix 58
Virtualization Services
The smart grid will cover an expansive territory. The cost to create information networks covering such
an area can be prohibitive especially considering the need to support the diverse array of smart grid
systems and system users. Although carriers already offer multi-purpose networks, there will be a
growing need to adopt network virtualization services to meet smart grid demands.
Virtualization services abstract physical and functional elements for a variety of purposes. Without
network-level virtualization services, transport services would become overly complex and expensive.
However, virtualization is certainly not limited to the network domain; in fact virtualization has its
roots in application layer systems. This section deals with network-layer virtualization, which offers
more transport service flexibility, to the point of supporting dynamic virtualization.
There are numerous reasons to converge multiple networks onto a common platform. First, networks
are becoming increasingly powerful offering the ability to reduce their associated capital and operating
costs. Second, networks needing to be converged and virtualized are increasingly relying on each other
for smart grid capabilities; it is easier to manage the interactions between those networks at multiple
layers when they are converged and virtualized on a single platform.
The network architect must be concerned with how virtualization supports the needs of smart grid
applications and how it impacts the network. First, virtualization should serve the business and
technical requirements of the use cases. The virtualization architecture should address performance
concerns including address bandwidth allocation, latency, collision avoidance, virtualized Layer 2
domains, failover and so on. Second, virtualization must consider how to establish service boundaries,
whether and what layers of the OSI stack can be virtualized sensibly. Finally, virtualization must
support appropriate security on the virtual domains.
Reasons to converge multiple networks onto a common platform are numerous. Networks are
becoming increasingly powerful offering the ability to reduce their associated capital and operating
costs. But while it is technically achievable to utilize a common physical platform, there is justification
for making it function as if it were many virtual platforms. For example, suppose multiple operational
owners need to allocate only their specific costs to their business unittherefore it would be important
to have a mechanism to support ownership virtualization to allocate traffic capacity and insure against
cross-subsidies. Some devices on the common platform may require access by a small subset of users,
thus requiring a logical separation of the network for security reasons. Another scenario could have
subsets of devices in the network sharing a community of interest with other adjacent devices, making
virtual network zones appropriate. Therefore, the architect has many options available to establish the
logical virtualization architecture best aligned with the lines of business, security, and performance.

Appendix 59
The next step is to determine how network virtualization supports application performance within the
various network domains. It is likely multiple technologies will be used in each domain. Therefore a
plan to accommodate virtualization at the physical layer and the requisite mapping between network
technologies is needed. Furthermore, most virtualization must be then extended across several
domains to accommodate end-to-end support. The virtualization architecture should address
performance concerns including address bandwidth allocation, latency, collision avoidance, virtualized
Layer 2 domains, and failover.
The architect must then consider how the virtualization architecture addresses security and traffic
isolation. Virtualization is by no means the final answer to security but it can be an important
contributor. Virtualization helps control who can access devices, what network they reside on at the
logical layer, and the degree of exposure devices may have to undesirable conditions (whether
purposeful or accidental). For example, a misbehaving device flooding the network in one virtual
domain shouldnt adversely affect other virtual domains on the same infrastructure.
Management Services
The smart grid requires increased interactions between the power systems, information systems and
network systems; therefore a common management infrastructure across all the systems is warranted.
Accordingly, this Smart Grid Management Services section will address the management aspects of the
power and communications network connecting all power grid components, functions and services.
The integration of the ICT architecture with energy management systems and domains provides a
centralized way to manage the entire smart grid, including the communications network and power
grid devices.
Business Drivers
The management vision for the utility smart grid architect should be to devise a path towards a
common management platform for the various smart grid systems, functions and projects. The
common management platform will ideally serve the management needs for all smart grid use cases.
The following are the business drivers for the management services architecture:
The number of use case actors warrants zero or one-touch management schemes across smart grid.
The use cases complexity implies managing policies at a business level (not at the actor level).
The variety of utility and third party entities involved in use cases requires good measurable metrics
for each of the management schemes
As new smart grid projects and corresponding systems emerge, the new functionality needs to be
easily incorporated into the existing management infrastructure
The scope for this chapter is any device which communicates and can be controlled through
configuration, including communication networks, applications, servers, configurable IEDs, etc.

Appendix 60
This section first introduces existing management architecture literature for the smart grid architect to
consider. Next, the layout and categorization of different management function types is covered.
Finally, an example use case is presented covering how management functions can be categorized and
organized.
Existing Management Architecture Literature

Existing industry standards include Telecommunications model (TMN), ITIL (Information Technology
Infrastructure Library) and Open Systems Interconnect (OSI)
TMN: The Telecommunications Management Network is a protocol model defined by ITU-T for
managing open systems in a communications network. The TMN model consists of five layers,
where Business Management is at the top, Service Management is the second layer, Network
Management is the third layer, and Element Management the fourth layer with the physical network
elements is represented in the bottom layer. We are proposing placing the Smart Grid Management
Systems at the Business Management layer in order to enable future integration with these systems.
The Open Systems Interconnect (OSI) group has defined management functionality in network
operations as shown in the five categories listed in table below. This same model has also been
adopted and supported by the standards body, ITU-T. This categorization is a functional view and
does not attempt to describe business related roles within a telecom or data network. The FCAPS
sub-functions within one of the five major groups are typically performed at differing levels within
the TMN model described in the TMN section. For example, fault management at the element
management level in TMN is detailed logging of all discrete alarms or other events. The element
management level then filters and forwards alarms/events to the network management level where
alarm correlation, corrective action and other actions take place. The FCAPS table below represents
common examples of the sub-functions performed under the model definitions. Different
applications of the model will typically contain sub-functions specific to the network operations
management center involved.
TMF eTOM: TM Forum's Business Process Framework (eTOM - Enhanced Telecom Operations
Map) is a key element of the TM Forum Framework Integrated Business Architecture. It is the
industry's common process architecture for both business and functional processes and has been
implemented by hundreds of service providers around the world. During this phase we will be
addressing all the Operations aspects of the data communications network enabling the smart grid.
Within Operations, we will focus on Assurance and Resource Management (application, computing
and network).
ITIL: It is the most widely accepted approach to ICT service management in the world. ITIL
provides a cohesive set of best practice, drawn from the public and private sectors internationally. It
is supported by a comprehensive qualifications scheme, accredited training organizations, and
implementation and assessment tools.
While the smart grid architect needs to assess the present ICT management architecture and assess the
integration of the smart grid management in the present architecture, the rest of this section will focus
on the management functions in general and the application of the management functions to smart
grid.

Appendix 61
Smart Grid Management Functions

Management services for smart grid can be viewed in several different ways. First, smart grid consists
of elements across multiple utility domains (consumer, distribution, transmission, generation, markets,
etc) and technology domains (communications, applications, servers, wireless, video etc) that need to
be managed. Second, from a System-of-Systems perspective, smart grid can be organized into
systems, which need to be managed. Third, each of the systems interacts with each other for specific
use cases, which also need to be orchestrated and managed. The following section will organize smart
grid management services as layers accommodating the above-described functions.
Organization of Management Functions

The following is the organization of management functions for smart grid into the three areas
described above - the management functions applicable for actors (which we call Element Management
Layer), management functions applicable for systems (System Management Layer) and management
functions applicable at the use case level (Services Management Layer). Each management function in
the Services Management Layer will make use of various functions in System Management Layer and
Element Management Layers.
These different management schemes can be organized in the following way
Figure 43 - Management Layer Organization
Each layer in Figure 43 is discussed below.
Element Management Layer

The following are the different management functions and corresponding processes involved in
element management:

Appendix 62
Lifecycle Management: Life cycle management is the service dealing with automatic device
discovery, automatic update of firmware, and automatic provisioning into the system. The
service also deals with secure decommissioning of devices. Life cycle management and its
automation are critical to smart grid management due to the large number of relevant devices.
System turn-up
Auto-discovery
Provisioning
Change management
Decommissioning
Technology/control plane management: smart grid is comprised of various technologies,

whose control plane needs to be managed. The technologies include the following:
Routing and switching, including control plane and data plane services
Wireless
Mobile
Systems Management Layer

The smart grid architect must support the following common management functions across systems:
Event Management: The following are the event management functions
Collection of power/cyber events from all grid and communication assets
Analyzing and correlating the events for actionable incidents
Taking the corresponding action
Security Management: The following are the security management functions that need to be
managed across systems (example: key management when a DA system needs to talk to an
AMI or a Transmission system)
Access control management
Security monitoring
System audit
Configuration Management: Configuration management includes any configuration changes

on the end assets (network, data, information, application, electric) including settings, firmware
upload and down load. The smart grid architect needs to plan for a common configuration
management platform for different smart grid projects and different types of electrical and
network assets involved

Appendix 63
Services Management Layer

The above management functions apply for actors and systems The smart grid architect needs to
analyze each use case in scale and analyze the management requirements. The following are the
management functions that would apply at the use case level (Services/Business Management Level):
Performance Management: This includes tuning the assets for the quality of experience that is
required for the use case. Bandwidth and latency provisioning, quality of service provisioning will
be part of the performance management.
Policy management: this category is the management of business policies across the enterprise. This
could be security policies such as NERC CIP or any business policies such as disaster recovery and
management, change management, etc.
The services management layer would use the systems management layer and element management
layer functions for end device configuration.
Figure 44 depicts the management layers, each management function inside the layers, and their
applicability to the actors, systems and use cases.
Figure 44 - Smart Grid Management Layers


Appendix 64
Conclusion
The smart grid management architecture has to be constructed in a way supportive of a common
management platform for the various smart grid systems. The architecture also has to strive towards
the services management layer which can orchestrate the systems and corresponding elements
involved to achieve the SLAs demanded by use cases non-functional requirements. The smart grid
architect should also tactically choose standard protocols and local management policies whenever
possible as explained below:
Standard protocols: The EA needs to strive to adopt and encourage standard protocols for
management such as SNMP, Syslog etc. IEC 61850 has features that could be used for configuration
control and management. Standards based management functions will be easier to integrate for
cross project management capabilities.
Local and centralized management: The EA needs to strive for local management schemes in
disaster recovery scenario.
Structural Model Framework Template

The SGRA Section 5, Smart Grid Reference Architecture Views, contains a structural model for each
view (Application Services, Analytics Services, Data Services, Control Services, Security Services,
Communications Services, and Management Services). Each is provided to help the smart grid architect
consider how to best deploy the various services using a stylized representation of a typical utility
network infrastructure. The template for these models is provided below [Figure 45] to help explain
why services were distributed among the fourteen tiers in the template. The template graphical
representation on the left side is identical across all seven structural models in Section 5. The right-hand
table describes the devices and capabilities inherent in each tier.

Appendix 65
Figure 45 - Structural Model Template
The smart grid architect, once all seven structural models are created for the utility, should consolidate
the seven models into a single structural model for the entire smart grid. This consolidation exercise
can strengthen the overall architecture. For example, since most analytics require communication and
data support, any consolidated tier containing analytics, but missing these supporting services, should
be studied more closely. All architectural weaknesses need to be directly addressed with impacted
architectural views subsequently updated.

Appendix 66
Appendix C. Smart Grid Conceptual Architecture Project

(SCAP)
Background information on the Smart Grid Conceptual Architecture Project is provided on page ix.
Business Requirements
These top level business requirements are derived from the SCAP work done by the Smart Grid
Interoperability Panel (SGIP) Smart Grid Architecture Committee (SGAC). These 380 requirement
families abstract over 8000 more detailed business requirements identified by the SCAP (SGIP SGAC).
Customer Domain
Service Level data shall be collected to ensure service level agreements are met
Communications shall meet defined Quality of Services (QoS) requirements.
Shall be configurable.
Shall be able to operate at a sufficient granularity (e.g., individual customer).
Shall support continuous evolution of smart grids.
Shall support aggregated management of Customer domain assets.
Shall support recovery from an electric grid cold-start.
Shall support role-based authorization.
Shall assure access by authorized entities to data.
Shall employ non-intrusive load monitoring where appropriate.
Power Quality monitoring shall be supported.
Shall respond to dynamic incentive signals (e.g., price signals).
Shall leverage common infrastructure with other services (e.g., water management).
Shall provide outage restoration management.
Shall manage reactive power in customer loads (e.g., building energy management systems).
Shall support charging of electric vehicles.
Shall process demand response pre-event notifications.
Shall provide energy management.
Quality of Service (QoS) requirements shall be defined.
Shall support display of information.
Shall support manual override of automated actions.
Shall require permission to access Customer domain services from other domains.
Shall collect localized weather data.
Shall manage Service Level Agreements (SLAs).
Shall minimize load sags and swells.
Shall collect load characteristics.
Shall provide information in support of operational needs.
Shall collect energy production environmental impact data.
Shall support energy trading transactions.
Smart Grid Conceptual Architecture Project (SCAP)

Appendix 67
Generation Domain
Shall control a plant's compliance to meet contractual obligations
Require security
Require a high availability of information flows
Require a high accuracy of data
Data shall be managed across organizational boundaries
Require validation of the cost-benefit of the function
Shall facilitate islanding of the power system
Shall provide the ability to forecast
Shall facilitate control of generator power
Shall provide real time intelligence regarding equipment state
Shall provide real time management of equipment
Shall minimize impacts
Shall facilitate scheduling
Shall perform congestion management analysis on proposed energy schedules
Shall support commitment activities
Shall dispatch regulation units to provide voltage support based on emergency requirements
Shall maintain the facilities in operating condition
Shall facilitate the procedures particular to bringing a cold unit on line
Shall provide advanced notice of scheduled outages
Shall support minimum cost real time scheduling of generation units
Shall ensure that the overall system remains intact despite severe challenges
Shall facilitate monitoring of generator power
Shall facilitate control of generator emissions
Shall facilitate monitoring of generator emissions
Shall monitor equipment contingencies
Shall perform security analysis on proposed energy schedules
Shall provide high quality power
Shall provide ancillary services
Shall provide rolling reserves
Shall provide contingency
Shall respond to changes in customer load
Transmission
Shall maintain the topology of the system including the ends of all segments
Shall forecast alternatives for generation sources is to anticipate long term generation needs
Shall maintain transmission system in operating condition
Shall provide credible contingency information
Shall determine long term future transmission system needs
Shall have contingency plans for catastrophic events
Shall optimize planned maintenance down-time
Shall automatically collect information relating to system disturbances
Shall automatically adjust voltage to optimize network efficiency

Appendix 68
Shall adjust power flow to optimize network efficiency

Shall maintain the system within its limits of stability
Shall monitor the status of measurement equipment
Shall maintain load forecasts for all system equipment
Shall recommended changes to correct limit violations
Shall notify stakeholders of emergencies
Shall detect equipment fault conditions
Shall develop emergency response in case of catastrophic external events
Shall provide operating guidelines for interfacing with distribution companies
Shall provide short term forecasting for time frames of interest
Shall provide short term forecasting for locations of interest
Shall include DER in the balancing of demand
Shall use activation of interruptible loads to balance the system
Shall use rotating blackouts as a last resort to balance the system
Shall manage substation voltages to manage the overall system
Shall minimize transformer clipping conditions
Shall maintain characteristic (nameplate) information on all system components
Shall monitor equipment for equipment failures
Shall track which actors had access to what system at what time and the changes they made
Shall monitor the electrical flow characteristics at all major pieces of equipment in the system
Shall simulate future configurations of the network
Shall perform maintenance on the system to maintain the system in operational condition
Shall manage the protection schemes to optimize the system protection
Shall maintain the system within the frequency limits
Shall shed load as required to maintain system stability
Shall use wide area monitoring to prevent issues arising from incipient system instability
Shall implement optimum control actions to maintain system stability
Shall perform long term forecasting to support system reinforcement planning
Shall do long term load forecasting to plan back-up generation
Shall plan manual switching to prevent fault behavior
Shall estimate the remaining capacity in the system
Shall calculate system utilization to prevent overloads
Shall predict failure of equipment
Shall optimize usage of equipment
Shall schedule equipment replacement is to prevent failure of equipment
Shall dispatch field crews in an efficient manner
Shall do 3-phase monitoring of the system
Shall be able to do 3-phase unbalanced operation
Shall optimize VAR control
Shall support the integration of Storage
Shall be able to handle sudden shifts in power flow
Shall shed generation as required to maintain system stability
Shall perform long term forecasting to support system extension planning
Shall manage access to critical facilities
Shall dynamically rate equipment capacity based on environmental factors

Appendix 69
Shall perform phase to phase balancing actions
Service Provider
Shall provide electrical service to its customers
Shall provide electrical service to its customers that is of high power quality
Shall be capable of detecting outages
Shall employ techniques to minimize outage occurrences and duration
Shall employ techniques to prevent damage resulting from malfunction of provider services
Shall develop techniques to avoid permanent damage to the environment in the course of providing
electrical service to its customers
Shall provide information enabling the customers to make decisions on their DSM participation
Shall provide a Demand Side Management function that is available
Shall be capable of directly controlling customer loads.
Shall provide a means of classifying information that allows for some data to be treated in a
Confidential manner.
Shall provide communication capability that is available.
Shall provide a method of communications that provide 'rapid response' with a goal of maintaining
load/generation equilibrium.
Shall provide a communication capability that is accurate.
Shall provide accurate individual meter readings to authorized parties.
Shall provide a means of obtaining information from customers
Shall establish two-way communication with customers.
Shall be capable of obtaining readings from customer meters in a manner that minimizes reading
errors.
Shall provide a means of efficiently obtaining information from meters.
Shall provide a means of obtaining accurate information from meters
Shall read meters in a manner that is convenient to the customer.
Shall implement accurate meter reading
Shall provide means of communicating with customers
Shall provide price of electricity information to their customers
Shall provide individual meter readings to its customers at intervals that are aligned with customer
needs
Shall enable selling energy to customer
Shall enable buying energy from customer
Shall provide forecasts of demand for planning purposes
Shall be capable of aggregating customers
Shall bundle services
Shall provide energy information services
Shall provide power quality services
Shall provide sub-metering service
Shall provide technical support services
Shall provide billing services

Appendix 70
Distribution
Shall maintain a topological model of distribution circuits in near real-time
Shall manage Intelligent alarm processing
Optimizes Voltage in relation to Reactive Power
Shall manage Voltage
Shall support management of reactive power
Shall manage work crews for authorized field work
Provides distribution operation personnel with comprehensive training
Shall monitor power quality on the distribution system
Shall perform service restoration
Shall support improvement of power quality
Shall provide an audit trail
Shall manage power quality information available from within customer sites
Shall prepare for storm conditions
Shall prepare for storm conditions
Shall manage unbalanced current flows
Shall manage unbalanced three-phase voltages
Shall adjust feeder loads for optimal load flow
Shall support Distribution Power Flow analyses
Shall support Contingency Analysis
Shall rank contingencies
Shall perform Fault Level Analysis
Shall support Short Circuit Analysis
Shall support Contingency Load Transfer
Shall support technical Loss Minimization
Shall support state estimation
Shall support monitoring of state
Shall support planned outage management
Shall support distribution planning
Shall support field crew root cause analysis of distribution system problems
Shall support transformer management
Shall locate Faults
Shall isolate Faults
Shall manage system protection
Shall manage system protection
Shall support diagnostic analysis
Shall support the management of Distributed Energy Resources (DER)
Shall support real-time emergency operations
Shall support outage management
Shall support distribution asset management
Shall support transmission operations
Shall support updating field equipment
Shall support system protection
Shall support short term load forecasts

Appendix 71
Shall support equipment level configuration management

Shall support the development of the future distribution model
Shall locate non-technical losses
Shall support condition based maintenance
Markets
Shall maintain an adequate operations platform
Demand Response (DR) maintenance staff test Demand Response (DR) equipment is to validate the
interconnecting infrastructure to allow the DR's to participate in the market operations
Identical generation devices is to provide electrical power to residence while remaining in parallel
with Energy Service Provider (ESP)
Shall provide clear location based price signals that serve as a value benchmark for consumers to use
as input in deciding when they use electricity
Will enable customers aggregators to directly access the market
Will enable demand-response aggregators to directly access the market
Will provide location based price signals that reflect locational differences.
Will correctly reflect the price of energy
Will correctly reflect the price of renewable energy
Will correctly reflect the price of emissions
Will correctly reflect the price of transmission
Will correctly reflect the price of reactive power
Will correctly reflect the price of harmonics
Will operate in a nodal fashion
Will operate in a regional fashion
Will provide forward pricing signals
Will provide hedging contracts
Will provide long term contracts
Will provide historical pricing history
Will provide historical demand
Will provide forward demand curves
Will coordinate cross market trading
Will provide clearing of bi-lateral contracts
Will provide registration of market participants
Will provide direct access to the wholesale market for large enough end users
Will provide access to trading analytics
Will provide a safety valve for runaway trading
Will verify the ability of a party to ability to cover their physical commitments.
Will clear the market
Will match counter parties to affect trades
Will permit net open trades to the limits of the system
Will net out trades
Will encourage the emergence of a market maker in each area
Will develop new trading vehicles
Will encourage the development of a transparent market

Appendix 72
Will encourage price discovery

Will encourage counter party transparency
Will register counter parties
Will provide settlement information for the market
Will encourage rapid settlement of the market
Will provide a dispute registration mechanism
Will provide a dispute resolution mechanism
Will maintain a counter party history
Will provide credit check capability
Will provide background check capability
Will create a framework of market rules
Will be able to determine the impact of market changes from simulations
Will provide location based grid state condition information
Will communicate information to all interested parties
Will retain a market history
Will communicate abnormal conditions to all interested parties
Will communicate all planned outages to interested parties
Will run product auctions for all applicable products
Will create long term demand forecasts by customer class
Will provide demand forecast for multiple near term time periods
Will provide demand response generation forecasts for multiple near term time blocks
Will create market products that are capability based i.e. technology agnostic
Will eliminate unnecessary barriers to entry
Will develop new market products that account for advanced capabilities
Will limit market exposure to the participant's credit limit
Will make all markets and products available to DR and storage if capabilities can be met
Will create products that encourage adequate capacity in the market
Will create products that can be used to balance intermittency of renewable resources
Will enable energy efficiency to participate in the market
Will support participation by distributed energy resources
Will create dynamic prices for all products and services
Will provide intermittent generation forecasts for multiple near term time blocks
Will develop new market products to price emissions
Will develop new market products for voltage support
Will develop new market products for VAR
Will perform power flow simulations of the grid
Will support exchange of network models with other stakeholders
Operations
Provide the ability to manage direct load control programs
Manage electrical frequency
Report the health of the primary equipment to the control center
Provide configuration management
Provide performance management

Appendix 73
Shall be able to authenticate end-use customers

Shall be able to communicate with end-use equipment
Shall be able to communicate with measurement equipment
Shall be able to communicate with mobile transportation loads
Shall be able to manage end customers in load programs
Shall communicate with end customers
Shall control the flow of power to individual end customers
Shall forecast resources
Shall implement black start
Manage restoration protocol
Shall manage ancillary services
Monitor DR/grid interaction
Shall manage power quality
Shall manage reserves
Shall optimize asset utilization
Shall provide intermittent generation forecast for multiple near-term time blocks
Shall manage power interchange
Shall manage the operation of the electrical grid
Provide voltage regulation
Shall be able to reconfigure (power) system
Schedule generation
Schedule transmission
Shall actively manage demand response programs
Shall be able to monitor micro-grids
Shall be able to provide historical information for any specific time-frame
Shall respond to abnormal conditions in a coordinated fashion
Shall validate demand response operations
Shall maintain emissions records for all operations
Shall maintain the state of the systems managed
Shall provide environmental monitoring
Shall provide demand side management
Assess the vulnerabilities of management systems
Shall Maintain a secure environment for operations
Shall maintain operations quality of service
Shall manage communications between physical locations for all information
Shall maintain load profiles of end customers
Shall measure energy consumption of customers
Shall provide information for Crew dispatching
Shall provide control information to distributed resources
Shall be able to access data from all distributed resources in a timely fashion
Shall be able to forecast weather impacts for any reasonable time frame in the future
Shall be able to manage the electrical protection of the system
Shall be able to simulate future operations of the system
Shall be able to minimize disruption of energy flow to end customers
Shall maintain topology information for the power grid

Appendix 74
Shall be able to schedule maintenance at times of least impact

Shall be able to support energy storage devices
Shall be able to support distributed energy resources
Shall manage voltage stability
Shall be able to request procurement of additional market products
Shall maximize available transmission capacity
Shall review Remedial Action Schemes
Shall perform contingency analysis
Shall manage scheduled maintenance requests.
Shall be able to analyze past grid events
Shall be able to directly dispatch resources in exceptional circumstances
Shall provide location based grid condition indicator
Shall manage time synchronization of the grid
Shall manage the variability of intermittent resources
Shall provide demand forecast for multiple near term time periods
Shall directly control end use devices
Shall communicate with neighboring control areas
Cross Cutting Domain

Shall Manage Records for Auditing
Shall Manage Records for Reporting
Shall manage authentication
Shall manage access control
Shall manage discovery services
Shall manage communities
Shall manage firewall policies
Shall Manage Privacy Policies
Shall manage end devices
Shall manage applications
Shall manage security policies
Shall manage distributed data
Shall manage calibration of field equipment
Shall manage non-repudiation
Shall manage communications continuity
Shall manage communications reliability
Shall manage communications availability
Shall manage personnel security credentials
Shall manage risk assessments
Shall manage services acquisition security policies
Shall manage security engineering practices
Shall manage Security Policy Exchange Service
Shall provide security services against Denial-of-Service attacks
Shall provide security assurance service
Shall manage enforcement of security policies for field equipment

Appendix 75
Shall provide a Trust Establishment Security Service

Shall provide secure mobility for field equipment communications
Shall provide support for multi-cast communications
Shall manage time synchronization of data
Shall test equipment prior to use
Shall manage underlying information support platforms
Shall manage vulnerability assessments
Shall manage network addressing
Shall manage network multi-homing
Shall manage transaction processing
Shall manage physical security of smart grid operations
Shall manage security of critical data
Shall manage communication faults
Shall manage communications performance
Shall manage accounting for communications use
Shall manage communications configuration
Shall manage residual risk
Distribution Automation (DA) critical data requires very high security
Smart Grid Business Services

Working from the requirements families listed above, the Smart Grid Architecture Committee (SGAC)
developed a set of business services distributed across the seven Smart Grid domains. In addition, a set
of cross-domain foundational business services was developed. In this section, the business services are
presented by domain. The actual company performing the service may vary by area of the country. For
instance, in California many of the market services belong to the California ISO; in Florida, there is no
ISO, so these services belong to the state utilities.
The SGAC team assigned to SCAP is developing additional use cases to define system requirements for
two domains in need the Customer and the Service Provider. For the Customer domain, the business
cases are from a customer point of view. For the Service Provider, the cases are from a non-electric
service provider point of view. Once this work is complete, it is expected the following Business
Services listings will change to accommodate the additional requirements.
Market Domain
Table 17 lists the SCAP business services required to support the overall business in the Market
domain. The actual operator of the business services will vary by geographic region.
Table 17 Market Domain Business Services
Name
Description
Check Background
Perform a background check on the participant
Check Credit
Confirm that the participant has enough credit to meet the requested transaction

Appendix 76
Name
Clear Market
Description
Clear Trades
Identify the most economically optimal schedule of resources while maintaining the
security of the grid.
Provide the ability to financially clear bi-lateral trades
Correlate Events
Predict future events by analyzing current patterns
Cross Market Trade
Provide the ability to trade energy products between markets
Develop Balancing Products

Develop Capacity Products
Develop market products that will provide the capabilities necessary to balance
intermittent supply resources.
Develop market products for capacity that encourages participation of various parties
Develop Distributed Energy

Products
Develop Energy Efficiency
Products
Develop GHG Emission
Products
Develop Market Products
Develop market products for distributed energy resources that encourages participation
of various resources
Develop market products for energy efficiency that encourages participation of various
parties
Develop market products for GHG emissions that encourages participation of various
parties
Develop new market products
DR Forecast
Provide forecast of demand response capability over multiple near term time periods
Exchange Network Models
Provide a mechanism to exchange network models between entities
Facilitate Market Maker
Actively encourage the emergence of a market maker in new markets
Facilitate Trades
Facilitate bi-lateral trades between parties
Forecast Intermittent
Generation
Grid Condition Indicator
Maintain History
Provide intermittent generation forecasts for various timescales as needed for grid
management
Provide a location-based dynamic metric that illustrates the desired change in energy
consumption.
Maintain a long term demand forecast for various customer classes within the control
area
Maintain a history of market transactions
Maintain Market History
Provide management of historical market information
Manage Aggregators
Determine mechanism for aggregators of energy resources to engagge in markets
Manage Direct Access
Provides the ability for end-customes to purchase power in the wholesale market
Manage Dispute
Provide a mechanism to coordinate disputes on the market processes
Manage Energy Contracts

Manage Market Rules
provide a mechanism to manage the operation of energy contracts between market

participants
Develop mechanisms to manage the evolution of market rules
Manage Notification
Provide notification of market events to interested parties
Manage Participation
develop guidelines for market participation
Market Transparency
Develop mechanisms to publish key market attributes to the public
Monitor Markets
Near Term Demand Forecast
Analyze the effectiveness of market rules in maintaining an effective electric power

market
Provide forecast of demand over multiple near term time periods
Net Trades
Will net trades across grid constraints up to the acceptable limit on that constraint
Outage Notification
Provide notification of planned outages to interested parties
Price Energy Products
Provide time based prices for energy products for individual customers
Protect Markets
Provides a mechanism to protect the market from potentially damaging trading behavior
Long Term Demand Forecast

Appendix 77
Name
Description
Provide Communication
Platform
Provide Demand Forecast
Provide infrastructure for secure, accurate and timely communication
Provide Demand History
Provide history of demand at all tracked locations on the grid
Provide Operational Platform
Provide infrastructure necessary to operate power market
Reduce Settlement Timeline
Develop mechanisms to settle market at the earliest possible time
Register Dispute
Provide a mechanism to register a dispute on the market processes
Register Participant
Provides a customer the ability to engage in market activity
Resolve Dispute
Manages the progress of a registered dispute through resolution
Settle Market
manage the settlement of market charges
Simulate Market
Provide mechanisms to simulate the power market
Simulate Power Flow
Provide simulation mechanisms to analyze power flow of the electric grid
Validate Commitment
Confirms the ability of a participant to provide their proposed commitments
Validate DR Resource
Interconnection
Validates that DR resources connection comply with relevant standards
Provide a forward looking schedule for energy requirements
Operations Domain
Table 18 lists SCAP business services required to support the overall business in the Operations
Table 18 Operations Domain Business Services
Name
Description
Analyze Event
Reconstruct the dynamic values of grid attributes around the time of a past grid event
Authenticate User
Confirm the identity of the user
Contingency Analysis
Calculate the impact of failures on the electrical power system
Control Energy Resources
Provide direct control of energy resources
Control Power Flow
Dynamically configure electrical power system to manage power flow to end-customer
Define Transmission Capacity
Define the dynamic safe operating limits of the transmission system
Demand Forecast
Provide forecast of demand over multiple near term time periods
Energy Measurement
Provide measurement of end-customer consumption
Forecast Resources
Provide forecasts of system resources
Forecast Supply Resources
Provide forecasts of supply resources
Forecast Weather Impacts
Forecast the potential impact of weather events on the grid assets
Grid Condition Indicator
Manage Configuration
Provide a location-based dynamic metric that illustrates the desired change in energy
consumption.
Maintain a time based model that represents the topology of the electrical power
network
Maintain configuration parameters of equipment
Manage Contingency Event
Provide pre-determined protocol instructions for responding to a contingency event
Manage Customers
Facilitate communication with end customers
Manage Demand
Provide a mechanism to reduce end-customer energy costs
Maintain Network Model

Appendix 78
Name
Description
Manage Direct Load Control

Program
Manage Distributed Energy
Resources
Manage Dr Program
Offer managed load reduction schemes using direct operation of devices
Manage Emissions Audit
Maintain emissions history for grid assets
Manage Energy Resources
Facilitate management communications with energy sources attached to the grid
Manage Energy Storage
Develop mechanisms to include energy storage in the operation of the electrical grid
Manage Frequency
Maintain electrical frequency within applicable limits
Manage Grid Operations
Balance supply with demand of the electrical grid
Manage Load Control Participants
Facilitate participant involvement in load control
Manage Performance
Maintain performance of equipment within applicable limits
Manage Power Interchange
Ensure power flow with neighboring control areas is coordinated
Manage Power Quality
Maintain attributes of the power flow on the system
Manage Quality Of Service (QoS)
Provide mechanism to ensure business services remain within predetermined metrics
Manage Reserves
Manage an inventory of reserves to cover contingencies
Manage System Protection

Manage System Re-Start
Provide protection schemes that ensure the security of the system under fault
conditions
Re-initiate stable operation of a power grid after a failure
Manage Variability
Provide reserves that can balance the variability of energy resources
Manage Voltage
Maintain electrical voltage within applicable limits
Minimize Disruption
Develop mechanisms to minimize interruption of electrical service to customers
Monitor Emissions
Measure the environmental impact of grid assets
Monitor Energy Resources
Report the status of energy sources attached to the grid
Monitor Equipment
Report the health of equipment
Monitor Resources
Measure the real-time status of grid resources
Optimize Asset Utilization
Identify dynamic limits for grid assets
Outage Analysis
Calculate the impact of maintenance requests on the electrical power system
Physical Security
Provide secure locations
Provide Black-Start
Provide the ability to produce power without first requiring power from the grid
Provide Connectivity
Maintain communication to equipment
Provide Demand Profile
Provide a time versus demand curve that represents the typical demand of a customer
Provide Historical Data
Provides information for requested time frame
Request Market Products
Provides the capability to request the procurement of energy market products
Review Protection Schemes
Reviews proposed remedial action schemes (RAS)
Schedule Generation
Identify economically optimal schedules for supply resources
Schedule Outages
Schedule Transmission
Schedules outages when they will have the least impact to the reliable operation of the
grid
Provide a mechanism to match supply schedules with transmission capacity
Schedule Work Crew
Schedule the appropriate resources for outage resolution
Simulate System
Provide simulation of the electrical power system
Develop mechanisms to include distributed energy resources (DER) in the operation of

the electrical grid
Offer managed load reduction schemes

Appendix 79
Name
Description
Synchronize Time
Validate Demand Response
Manage frequency so that a clock connected to the grid is kept within tolerance of a
reference clock
Evaluate response of resource to a demand response dispatch
Vulnerability Assessment
Assess the resilience of grid management systems
Service Provider Domain

Table 19 lists SCAP business services required to support the overall business in the Service Provider
Table 19 Service Provider Domain Business Services
Name
Description
Aggregate Customers
Bundle Services
Provide mechanisms to aggregate customers for various electricity buying and selling
options
Provide mechanisms to bundle various services
Buy Energy
Maintain protocols that enable buying energy
Classify Data
Provide predetermined protocols for classifying data
Collect Meter Data

Communicate Price
Collect accurate meter data from end customer in a manner that is convenient to the
customer
Communicate customer specific price of electricity information to end customer
Deliver Electrical Service
Deliver high quality electrical service to customers with in applicable limits
Detect Outages
Ensure mechanisms to detect outages
Direct Load Control
Control loads directly to respond to the reliability needs of the electric grid
Forecast Demand
Determine protocols for forecasting demand
Manage Accuracy Of
Communication
Manage Accuracy Of Information
Ensure communication of system parameters are accurate
Manage Availability Of
Communication
Manage Communication
Manage On-Going Two-Way

Communication
Manage Outages
Ensure communication of system parameters available to the customer within

applicable limits
Maintain communication of system parameters as they relate to customer decision
making
making
making
Collect accurate meter data with various levels of granularity from end customer
using protocols to minimize cost
Maintain communication channel with the end customer that allows two-way
communication
Maintain the distribution system to minimize outage occurrences
Obtain Customer Device

Information
Prevent Demand Asset Damage
Maintain communication channel with the end customer that allows two-way
communication
Ensure mechanisms to prevent damage to demand assets
Prevent Environmental Damage
Ensure mechanisms to prevent environmental damage
Provide Billing Services
Provide accurate billing data to customers in a timely manner
Manage Customer
Communication
Manage Energy Balance
Manage Meter Data Collection
Ensure communication of system parameters are accurate

Appendix 80
Name
Description
Provide Energy Information

Services
Provide Power Quality Services
Maintain energy information services that allow the customer to manage their loads
Provide Sub Metering Service
Make accurate sub metering data of various loads available to various authorized
parties
Provide technical support services that allow the customer to manage their loads
Provide Technical Support

Services
Sell Energy
Manage the quality of electrical service by ensuring that it is within applicable limits
Maintain protocols that enable selling energy
Share Meter Data
Ensure authorized parties have access to accurate meter data
Bulk Generation Domain

Table 20 lists SCAP business services required to support the overall business in the Generation
Table 20 Generation Domain Business Services
Name
Description
Analyze Schedules
Provide analytics to determine issues with planned operations
Balance System
Provide a mechanism to respond to changes in the supply-load equation that will

maintain the system within compliance limits
Provide a mechanism to discover the current characteristics of equipment
Discover Equipment Status

Least Cost Dispatch
Manage Cold Start
Provide a mechanism to allow for the lowest cost units to be called on first for
providing energy
Provide maintenance sufficient to maintain generation units in operational
condition
Provide the controls that will facilitate several scenarios for keeping the energy
flowing through the system when issues occur
Provide analytics to determine adverse impacts that can be managed before they
become operational problems
Provide a set of reserve resources that can be used to maintain the grid within
compliance limits
Bring an out of service unit on line as an independent source
Manage Contractual Compliance
Units have contractual commitments on when to run at what rate
Manage Control Of Generation
Provide a mechanism to directly control the inputs and outputs of generation units
Manage Data Sharing Across

Organizations
Manage Emissions From Units
Provide stakeholders in different organizations with required data
Manage Equipment
Provide a mechanism to control equipment operation in due time
Manage Forecasting
Provide a mechanism to create scenarios of future demand for supply capability
Manage Islanding
Manage Power Quality
Provide the ability to disconnect sections of the grid from each other to operate
independently
Provide a mechanism switch away from incipient failures to maintain the system
within compliance limits
Provide a mechanism to maintain energy quality within compliance limits
Manage Scheduled Outages
Plan out of service time for maintenance on generation facilities
Maintain Facilities
Maintain System Integrity
Manage Adverse Conditions
Manage Ancillary Services
Provide a mechanism that allows control of the emissions of a generation unit
Manage Past Incipient Failures

Appendix 81
Name
Description
Manage Scheduling Of Facilities
Monitor Generator Emissions
Provide analytics that will develop an operations plan for generation units based on
known characteristics
Provide a mechanism to confirm schedule operational compliance in generation
units
Provide a mechanism to measure emissions of a generation unit
Monitor Generator Performance
Provide a mechanism to measure generation unit operational characteristics
Provide Communications
Provide a way to coordinate different facilities operations regardless of outside

interference
Maintain business cases that provide traceability of project costs and benefits
Manage Unit Commitment
Provide Cost-Benefit Analysis

Provide Fail Over Options
Provide Security
Provide a mechanism to maintain the system within compliance limits when a

resource is lost
The expectation is that the generation units will provide enough reserve to allow
for the loss of part of the system
Transmission Domain
Table 21 lists SCAP business services required to support the overall business in the Transmission
Table 21 Transmission Domain Business Services
Name
Description
Balance Phases
Maintain the energy balance from one phase to another phase
Communicate Emergencies
Maintain channel to stakeholders to for emergency information
Conduct Grid Planning
Create scenarios for future system sizing to support possible load changes
Conduct Planning
Create scenarios for future system supply to support possible load changes
Conduct Short Term

Forecasts
Create Long Term Forecasts
Manage a set of near term projections for system use by location
Detect Faults
Monitor system for system faults (outages)
Dispatch Maintenance
Teams
Forecast Equipment Life
Manage the available workforce
Forecast Equipment Loading

Maintain Contingency Plans
Maintain Equipment
Characteristics
Maintain Physical Security
Maintain Stability
Maintain State Information
Maintain a set of simulations that can provide future loading projections on the system
Using the information gathered in monitor equipment determine the remaining life of
electrical components installed in the grid
Maintain equipment specific future load profiles
Develop plans, including fail over, that allow the system to continue to operate when
problems arise
Maintain all characteristics of electrical components installed in the system
Manage the physical facilities of the system to maintain control of physical access to the
system
Manage energy flow in the grid to ensure stable grid operation
Maintain System
Using the information gathered in monitor equipment determine the remaining capacity of
the system to handle more energy
Manage the maintenance of the system equipment to maintain operational capability
Maintain Topology
Manage the mapping of the logical connectivity possible in the overall system

Appendix 82
Name
Description
Maintain Voltage
Manage embedded equipment in the grid to adjust voltage to stay within compliance limits
Manage Access
Manage a mechanism to monitor who accessed what when
Manage Blackouts
Operate a mechanism to manage rolling blackouts as part of an overall balancing scheme
Manage Demand Response
Operate a mechanism to manage interruptible loads as part of an overall balancing scheme
Manage DER
Manage DER as a part of the resource mix for balancing energy demands
Manage Emergency
Response
Manage Equipment Rating
Maintain a plan for recovering from major system disruptions
Manage Interconnect
Guidelines
Manage Load Limits
Using the information gathered in monitor equipment determine the current energy
capacity of each electrical component of the system
Maintain a mechanism for managing the exchange of energy with distribution
Operate equipment in a manner that avoids overloads
Manage Load Shed
Manage the system balance by shedding load
Manage Power Flow

Manage Protection Scheme
React to rapid changes in the energy flow to maintain system parameters within
compliance limits
Maintain a set of schemes for protecting the system from damage by electrical overload
Manage Stability
Manage energy flow in the grid to ensure stable grid operation
Manage Storage
Maintain the integrated operation of storage at any point in the system
Manage Supply
Manage Switching
Manage the level of supply in the system to balance the system while maintaining the
compliance limits
Manage a set of protocols to switch load on the system
Manage Transformer Load
Maintain the load on transformers to avoid distortion of the wave form
Manage Var
Manage VAR for all customers within compliance limits
Manage Voltage
Operate a mechanism to regulate voltage within compliance limits for all customers
Monitor All Phases
Monitor all three phases of the system for energy flow characteristics
Monitor Equipment
Operate a mechanism to maintain temporal characteristics on electrical components

installed in the system
Maintain status of accuracy for instrumentation in the field
Monitor Equipment
Accuracy
Monitor System Status
Manage instrumentation in the grid to maintain a picture of the grid situation
Operate Unbalanced
Manage the system will different amounts of power flowing on each of the three phases
Optimize Equipment
Manage energy flow so that equipment usage is optimized
Optimize Planned Outage
Manage the optimization of equipment availability for maintenance
Optimize Power Flow
Manage the flow of energy in the grid to minimize losses while supplying all demand
Regulate Frequency
Maintain system frequency within compliance limits
Simulate System
Shall manage a mechanism to create on demand digital simulations of the system
Distribution Domain
Table 22 lists SCAP business services required to support the overall business in the Distribution
domain. In most cases the distribution utility will operate all services. This is the only domain likely to
be similar from region to region.

Appendix 83
Table 22 Distribution Domain Business Services
Name
Description
Audit trail management
Condition Based Maintenance
This service provides the documentation necessary to provide an audit trail for system
event reporting.
This service manages automated service restoration functions. Measurement of this
service would follow accepted indices on system restoration performance.
This service manages condition based maintenance for distribution field equipment.
Contingency Load Transfer
This service manages contingency load transfers.
Contingency Ranking
This service ranks contingencies for distribution system operators.
Customer Power Quality

Information Management
Development of Future
Distribution Model
Diagnostic Analysis of
Distribution Systems
Distributed Energy Resource
Management
Distribution Energy Loss
Minimization
Distribution operations training
This service manages power quality information available from within customer sites
throughout the distribution system.
This service manages the development of future distribution systems
Automated Service Restoration
Distribution Planning
Distribution Systems Asset
Management
Distribution Systems Field
Equipment Configuration
Management
Distribution Systems Support of
Transmission Operations
Fault Isolation
Fault Level Analysis
Fault Location
Field Equipment Upgrade
Management
Field work management
Intelligent Alarm Processing
Loss location management

Manage System Protection
Execution
Manage unbalanced current
Optimal Load Flow
This service manages the diagnostic analysis of distribution system field equipment.
This service provides management of Distributed Energy Resources (DER) across the
distribution system.
This service manages the technical loss of energy to minimize losses on the
distribution system.
This service provides a comprehensive program of training for distribution operations
personnel.
This service manages the distribution planning processes.
This service manages distribution systems asset management processes.
This service manages the configuration of field equipment. Metrics for this service are
determined by emerging policies for maintaining field equipment documentation.
This service manages the integration of distribution systems in support of transmission
operations.
This service manages the isolation of faults to minimize damage to utility and
customer equipment.
This service manages Fault Level Analysis on distribution systems
This service manages the location of faults on the distribution system. Metrics for this
service would follow industry indices of system performance
This service manages the updating of field equipment
This service manages the dispatch of work crews authorized for servicing field
equipment
This service manages all levels of alarms to maintain correct operator action priorities.
The metric for this service is related to correctly handling the variety of alarms that
may be faced by operators.
This service manages the location of non-technical energy losses on the distribution
system.
This service manages system protection post event analysis; This service manages the
analysis of protection actions following an event episode.
This service manages unbalanced current flows to keep distribution systems within
acceptable engineering tolerances to optimize efficiency.
This service optimizes load flows on the distribution system

Appendix 84
Name
Optimize Voltage to Reactive
Power
Outage Management
Description
Planned Outage Management
This service manages voltage in relation to reactive power within the distribution
system.
This service manages outages on distribution systems. The metric for this service is
related to system reliability indices.
This service supports planned outage management for distribution systems.
Power Flow Analyses
This service manages the Power Flow Analyses processes.
Power Quality Improvement
This service manages the improvement of power quality within the distribution
system.
This service monitors power quality on the distribution system.
Power Quality Monitoring

Prepare Static Systems for
Storm Conditions
Reactive Power Management
Real-Time Emergency
Operations
Root Cause Analysis
This service includes the management of static preparations in anticipation of system

disturbances due to impending storm conditions
This service manages reactive power on the distribution system to maintain reactive
power
This service manages real-time emergency operations within the distribution system.
Short Circuit Analysis
This service manages the support of field crew investigations into root cause analysis
of distribution system failures
This service manages the analysis of short circuits within distribution systems
Short Term Load Forecasts
This service manages short term load forecasting
State Estimation Support
This service manages the state estimation process using available information
available from field equipment.
This service manages system protection functions
System Protection
System State Monitoring
Topological model
management
Transformer Management
Voltage Management
This service manages the migration to state monitoring making use of increasing
numbers of field devices that have monitoring capability. Metrics for this service
would be the reduction in the band of error surrounding system state.
This service maintains the topological model to maintain the system model in near
real-time.
This service manages the life-cycle of transformers in field operations
This service manages customer service delivery voltages to stay within industry
accepted tolerances
Customer Domain
Table 23 lists SCAP business services required to support the overall business in the Customer domain.
The actual operator of the business services will vary by geographic region.
Table 23 Customer Domain Business Services
Name
Description
Access Control Management
Provide a mechanism to support role-based access control to services.
Configuration Management
Manage configuration of the system.
Deployment Management
Manage ongoing revision of the system.
Energy Asset Aggregation
Manages a group of devices in the customer domain
Energy Management
Provide a mechanism to influence operation of devices to meet business energy-usage goals.
Energy Monitoring
Provide a mechanism to monitor aspects of energy as required to meet business goals.

Appendix 85
Name
Environmental Monitoring
Description
Information Presentation
Provide a mechanism to collect environmental data about the impact of energy supply
sources in the system.
Provide a mechanism to display information from the system.
Infrastructure Planning
Building the Smart Grid System to support additional devices (e.g. Water, Gas)
Manual Override
Provide a mechanism to override automated actions while assuring safety.
Non-Intrusive Monitoring
Derive device load levels using non-intrusive measurements combined with analytic
methods.
Provide a mechanism to mitigate impact power failures through use of alternate energy
supply sources.
Outage Management
Smart Grid Cross-Domain Foundational Services

Cross Domain Foundation services are relied upon by all business domains and are therefore required
to be interoperable across domains to enable flexible and resilient grid architecture. For example, two
domains utilizing disparate encryption mechanisms will require additional work to support their
interaction and be indicative of architectural fragility.
Cross domain services break down into three basic groups:
Security
Communication
Data
Each group is discussed below.
Security Services
Central Security Services are comprised of Automated Services as well as the Managed Services
responsible for configuring the Automated Services. Automated Services require no human
intervention once configured and are built for speed and efficiency, whereas Managed Services expect
user input to set configurations, preferences, etc. for the particular characteristic being managed. The
NISTIR 7826 Security Requirements have been translated into the security services in Table 24.
Table 24 Security Services
Name
Description
Access Control
Manages the secure admission. (see Central Security).
Account Management
Maintains actor security credentials
Alarming
Provides a mechanism to pass alerts to actors
Archive
Providing an accurate long-term copy of information
Audit
Provides a rigorous review of actor actions
Audit Qualification
Provides a trusted method to determine that audit actors are competent
Authorization
Provides permission for an actor to take an action
Backup
A process that provides an accurate alternate copy of information

Appendix 86
Name
Description
Camouflage
Hiding items from unauthorized actors
Central Security
Challenge Management
The Central Security Service shall maintain a database of transaction permissions at

the component level. Specifically, the Central Security Service explicitly defines which
users and components have permission to perform what transactions in what context.
All Smart Grid end-users and components must verify sufficient privileges prior to
execution of any transaction instruction.
Maintains a secure challenge process for actors
Classification Management
Manages the labeling of sensitive information
Compliance Management
Maintains a process to ensure that actors have not violated security policy
Configuration
Arranges the pieces to provides an authorized whole
Continuity
Provides for actors to continue to securely function at an acceptable level
Control Management
Maintains a set of limits on an actor's access
Corrective Action Management
A process to ensure that any security issues are closed
Disposal
Provides a trusted process to remove information permanently
Distraction
A process of enticing unauthorized actors to interact with decoys
Encryption
Provides a mechanism to encode information in a secure fashion
Entry Management
Provides a mechanism for allowing an authorized actor access
Identification
A trusted process of determining the identity of an actor
Identity Management
With the large number of end-users of Smart Grid, including the customers, utility
employees, grid control operators, etc., the Smart Grid components must provide
unique and traceable identification of each user as well as data with each message and
transaction.
provides a method to report security breaches to a trusted authority
Incident Reporting
Information Release
Management
IPR management
Allows control of information to be passed to other actors
Key Management
Provides a trusted process to maintain the security of a secret
Life Cycle Management
A process to manage the cradle to grave security
Log Protection
Provides a mechanism that keeps logs from being tampered with
Logging
Provides an auditable trail of actors access
Non-Repudiation
Provides a mechanism to prove that a specific actor took a specific action
Parameter Monitoring
Watching the edges of a physical location for unauthorized actions
Password Management
Manages the process of dealing with all actor passwords
Penetration
Provides a mechanism to test the security environment for vulnerabilities
Physical Security
Provides a process to ensure that physical items are secure from unauthorized access
Privilege Management
Maintains the privileges for actors
Reliability
Provides a process to monitor actors for unexpected changes in behavior
Response Management
Provides a mechanism to manage actor actions for alerts
Retention
Provides a process to determine parameters for saving information
Risk Assessment
Determines the risk associated with the security environment
Risk Management
Maintains an assessment of the vulnerabilities in the security environment
Role Management
Manages actor roles
Screening
Maintains a trusted process for reviewing actors for credentials
A process to manage rights to use intellectual property

Appendix 87
Name
Description
Security Assessment
Provides a mechanism to determine security needs
Security Authority
Provides trusted resource that can authorize changes
Security Management
Maintains the overall security environment
Security Monitoring
The analysis of collected information on the status of the security environment
Security Policy Management
Creates an overall policy for security
Security Reporting
Provides a mechanism to inform trusted actors
Security Test Development
Provides a trusted process to develop test processes for security
Security Training Management
Provides actors with training required to maintain their credentials
Separation Management
Provides a mechanism to ensure that an actor does not have multiple security roles
Threshold Management
Provides a mechanism to set parameters for generating an alert
Time Stamp
Provides an auditable mechanism for attaching accurate time to an action
Update Management
A process that updates to the security system navigate prior to being placed in service
Vulnerability Assessment
Determines what potential security holes exist
Vulnerability Management
Provides a mechanism to monitor the status of security holes
Communication services are fundamental to electric grid operations. They underpin the means by
which devices become intelligent, for information to flow, controls to be executed, and for people to
manage utility functions and services. Movement toward a smarter grid will necessitate vast quantities
of new smart devices to be implementedall needing some form of communications. The fact that
many of these devices dont yet exist adds to the challenge. As the devices are implemented, their
functionality and value will expand as grid operators figure out innovative ways to leverage smart
device intelligence. Thus, it is imperative for the Smart Grid communication architecture to be
extraordinarily forward looking and accommodating.
At the communication services layer, the following functions are required:
1.
2.
3.
4.
5.
Transport services to move information around the network,

Virtualization services to help segregate and optimize transport services,
Control services to help manage information flow and support endpoints wanting network access,
Gateway services to facilitate legacy applications to utilize next generation networks, and
Mobility services to support roaming or mobile endpoints.

Appendix 88
Figure 46 - Communication Services Layer Functions
Table 25 lists the network and communication services required to support the smart grid.
Table 25 Communications Services
Service
Access Of Media
Address Management
Administration Service
Alerts
Application Caching
Assured Delivery
Asynchronous
Messaging
Atomic Multicasting
Automated Messaging
Automated Process
Automatic Call Routing
Backbone
Backup
Broker Support
Description
The capability for a user to view specific Library Mgmt System functions depending on the "Set-up
and Control" for that user e.g. searching more than one repository.
Assignment and maintenance of dynamic device addresses to ensure that there are no duplicate
addresses on the network
The maintenance and management of local policies, activities or procedures.
Notification using some mechanism (e.g. SMTP message) that a message was delivered/notdelivered/dispatched/rejected/accepted.
The capability of the system to provide the capability to cache objects, pages etc to optimize
access speeds. This includes caching for static and dynamic pages.
The ability to know that when a message is sent thru or between systems that the message will
either be received or that notification will happen to the originating system or a designated
operator
Fire and Forget messaging system that exists between source and target applications or/and
databases.
The capability to send a message to more than one target. The message can be atomic (fire and
forget).
Machine generated messages that are sent to specified addresses in pre-designed formats
Event triggered machine operations with a pre-designed set of routines
Using the header information of a telephone message to send the call to a specific hand set or
one of a bank of handsets
The high speed interconnect on the network that provides the location where multiple systems
and users can exchange data. (NOTE: The backbone may be wholly contained in a single device
such as an enterprise router)
The processing of saving documents for storage to another storage medium e.g. disk for
retrieval/restoration as needed. Backups are normally removed to another location for safe
storage
The ability to manage exchange of information between systems and processes through a central
controller

Appendix 89
Service
Call Groups
Capacity Management
Capacity Monitoring
Chat Management
Collaboration
Computer Telephony
Integration (CTI)
Configuration
Management
Connection Pooling
Connectors
Content Delivery
Data Acquisition
Data Cleansing
Data Distribution
Datastream
Conversion
Delivery Assurance
Delivery Mgmt Service
Dial-In Management
Services
Directory Framework
Management
Directory Framework
Parameter and Control
Set-ups
Dispatch
Description
Maintenance of an automated list of radio handsets that make up the radios attached to a
specific transmitter on a specific frequency and the unique identifier of each handset, so that the
radio call goes to the right transmitter and the right handset
The ability to create and manage the rules required to determine how resources will be assigned
to the available services
The ability to monitor the loads and performance of the systems to determine when the system
either needs additional resources assigned or should shed tasks or users
The ability to set rules and define forums or private areas for on-line chat for collaboration or
discussion
Allows near real-time cooperation between two or more people in two or more locations to
communicate, operate on the same data and see each other's operations and results in an
interactive fashion as though they were in a meeting
The ability to use a computer to answer the phone and/or to provide information automatically
to the human on the answering end of the phone to support the processing of the call in a faster
and more orderly fashion
The ability to manage the system software, application, system settings, and user information on
similar devices automatically and from a remote location
Connection pooling allows the efficient use of data access services. The creation and ripping
down of a connection to a database takes up valuable processing cycles pooling allows a
connection that is already existing to be used by many separate processes (by queuing requests).
By managing a fixed number of connections (which can automatically be increased in multiples),
the connection time overheads are largely removed, resulting in potentially significant
performance benefits.
Exposure of functionality (application or databases) that enables an application or database to
conduct transactions (CRUD) with the target.
Involves the delivery of content to a particular channel
Collection of a stream of data from instrumentation and sensors that either constantly send data
or are trigger driven, the acquisition has to collect the data and store it for each required reading,
no unanticipated down time is acceptable
An automated process of reviewing data for impurities and correcting these defects automatically
if possible, based on a set of defined rules, logging all errors for manual review
The ability to transport from a central master data set information to remote locations
Translate incoming and outgoing data (or sets of transactions) into the required formats based on
business rules supporting one or more clients/systems on the fly
The ability to assure delivery of a message packet to another system or notify the sending system
or a designated operator
Management of delivery of services either by internal or external resources, ie collection of waste
materials. Monitoring of inventory of items, ie bins.
The ability to manage the occasionally connected data lines from various partners and customers,
with regard to quality of connection, connection time and security
The Management activates of the System Directory, includes distributed management.
Configuration, Set-up of seed data, business rules , business defined criteria that govern the
Directory. May actually call other services such as Users, Groups, Authorizations, etc.
Firing of the message to the Messaging Service or Network Interface Service.

Appendix 90
Service
Domain Name
Services
Electronic Messaging
Enterprise Storage
Event Monitoring
Event Notification
Events Flow
Exception
Management
External File Transfer
Fault Monitoring
Gateway Control
Gateway Management
Gateway Services
Information Exchange
Infrastructure
Management
Infrastructure
Monitoring
Infrastructure
Prioritization
Integrated Voice
Response (IVR)
Inter-Network
Connections
Interactive White
Board
Interconnection
Services - Network
Description
Creation and maintenance of a cross-reference list of physical addresses, routes and aliases for
devices on the network (internal and possibly external), so that humans can enter the alias to
automatically communicate with the desired device using industry standard
The use of digital distribution of information over a network that may or may not extend beyond
the enterprise with a central distribution and addressing center
The ability to share storage between services and applications within the enterprise to provide
flexibility and management for the storage media and the content of the media
Creation, monitoring and extraction an auditable log of events and using pattern matching to a
set of pre-defined rules to alert an operator of an abnormal condition. May also feed alerts to a
device for further processing or process control
Notification to a user or device that an event has occurred, implemented thru a series of rules
and devices, so that the system will keep escalating utilizing different methods or addresses until
it is successful in delivering the alert
the ability to orchestrate a cascading set of events in an automated fashion thru a broker or other
central controller
Provide reports of incidents in any service in the enterprise.
The ability to send a digital package of information via a standard transfer service between
locations (e.g. FTP)
The ability to monitor the services for unexpected operations and determine the cause of the
issue - then report the issues to an appropriate location based on rules
The ability to control the flow of information thru either an internal or an external gateway based
on the rules that have been installed in the gateway
The ability to create and maintain the rules that will be used to determine how a gateway will
react to specific messages, either from the addressing or the content of the message
The ability to use a central director to determine how to route specific digital documents and
information around the enterprise or to and from partners
Automated transfer of data between two or more applications or two or more databases based
on pre-defined keys, formats and rules
The ability to remotely maintain the infrastructure in the organization including creating and
maintaining rules about resource prioritization, allocation, administration authority, etc.
The ability to monitor what is happening in the enterprise infrastructure, log any events that are
not expected, and notify an administrator based on the notification rules
The ability to determine which service or information should go first, when there is contention for
the resources that comprise the infrastructure
The ability to use technology to create and maintain call message hierarchies that are used to
interact with inbound callers to provide information for standard queries without the
intervention of a human operator and record the results of the query. The IVR normally has the
ability to route the call and any information gathered to a human operator if the query cannot be
successfully answered
The ability to peer with or connect to foreign network for communication, both networks that are
controlled by partners and those that are public networks
A process and supporting software to allow two or more people at two or more physical
terminals to view an electronic chalkboard and to add information to the chalkboard that is
visible to everyone else in the session. Change ability can be controlled via security services
The ability to connect (or peer) one or more networks together using standard industry protocols

Appendix 91
Service
Interconnection
Services - Wired
Interconnection
Services - Wireless
Intermittent Services
Internet Access
Link Management
Linking Services
Log/Audit
Logging
Message
Completeness
Management
Message
Composition/
Decomposition
Message Filtering
Message Logging
Message Routing
Message Translation
Mobile
Mobile Device
Management
Network &
Connectivity
Management
Network Caching
Network Device
Maintenance
Description
The ability to physically connect devices so that they can use standard protocols to communicate
both with other devices and with the enterprise
The ability to connect devices so that they can use standard protocols to communicate both with
other devices and with the enterprise over an Radio Frequency carrier
Services which can be started and stopped, either by demand, or by rule or by administration
which can be used to change the behavior of the rest of the environment (e.g. an intermittent
service to re-route traffic because of a denial of services attack for a commercial web site)
Provision to allow authorized users and devices productive access to the Internet using IP
protocols
Maintenance of specific legs in the network, providing health information on the link to the
operator, so that adjustments can be made
The Capability to access other modules functionality in the application e.g. accessing property
module to associate people, rates or licenses.
Record the master data management system and master data management service events,
normal and abnormal. The full Audit service provides all the logging necessary to support a rich
history of master data management processing events. In practice the Audit service may rarely be
used to its full capacity, partly because the Audit service may have an impact on the performance
of the master data management system.
Audit trail of jobs processed, manual interventions and incidents
The ability to detect when a message does not contain a complete payload and notify the sending
systems
Manages the copying of a message to different formats - utilizes the Transformation service, can
be utilized by multicasting. Also can involve breaking the message up into components.
The determination of where a message is allowed to be sent/received based on security and data
protection requirements.
Creation of a archival quality list of the header or header and body information of all the
information being passed between a specified set of addresses or with specific header
information
The ability to route messages from one system to another automatically
The Transformations from a source message to the requirements of the target.
The ability to disconnect from the network and work on standalone applications, supports bidirectional synchronization when reconnected to the network
The ability to create rules about how mobile devices connect to the enterprise and what
requirements have to be met prior to allowing access (e.g. authentication, authorization, patch
level, etc)
The ability to create and maintain the rules by which a network can connect to another network
either with a partner or a public network
Caching is often used to improve performance of systems, by moving the data nearer the
consumer. This can be by caching data in memory for database access, caching networked data
on a local storage device for network access, caching pre-constructed Web pages and other
information for use either externally (often referred to as reverse caching) or internally (reducing
network usage).
The ability to remotely manage the health of a network device and update any firmware or
software installed in the device

Appendix 92
Service
Description
Network Device
Security Management
Network Interfaces
The ability to remotely manage the rules, settings and permissions for the secure operation of the
netowork
Provide network access outside the Local Area network (other LANs in the Wide Area or external
networks)
Management of the network devices including: routers, hubs and switch monitoring and
configuration control
Logging, triggering (simple test) and analyzing (complex time delayed testing) the movement of
traffic on the network to determine the health of the network and alerting devices or humans of
problems with the health, based on a pre-defined set of rules.
The ability to monitor and automatically adjust the performance of a network or a portion of a
network
the ability to create and maintain a model of the actual network and to create traffic scenarios for
the network to determine when the network would run into contention and other operational
issues
The ability to allocate and manage the way services access nodes on a processing system
The ability to recognize that a message that should have been delivered has not been delivered
and make the appropriate re-tries or notifications
The ability to monitor and report the health of the notification process
Network Management
Network Monitor
Network Performance
Tuning
Network Traffic
Simulation
Node Management
Non-Delivery
Notification Services
Monitoring
Object Inspection
Path Tracking
Performance
Modeling
Portal
Private Wireless
Configuration
Management (Talkgroups)
Queue Management
Radio
Radio Frequency
Management
Real-time
Reliable Multicasting
Remote Access
Remote access
management
The ability to review object for integrity and replace or sequester objects that do not pass the
testing
The ability to determine the route that traffic took during the trip between locations including all
the devices that it crossed during the trip and time statistics
The ability to model a service and its supporting infrastructure and understand how the service
will perform based on scenarios of usage
Providing an individual human readable front end to the information and systems that they are
authorized to access, in a common format to hide the complexity of the underlying systems in a
commercially standard format
The ability to segment the user population by various parameters to efficiently use the limited
radio bandwidth that is available from a transponder
Handling of the incoming and outgoing queues of events, and messages -including the ability to
recognize priority items in the queue and move them forward, ensuring that all items are
released from the queue to the process that they are assigned to
Supports use of specific frequencies to send information thru the air between handsets and fixed
antennas using a known addressing scheme
Maintaining control of the specific radio frequencies that are licensed to the facility to reduce
non-productive messaging and optimize productive use
The ability to interact with data in a short enough period of time to effect the next operation on
the item reporting the data (e.g. acting on data that shows a broken drill bit in a tool, before it
can eject the current part and start on the next one) so that the required actions are taken within
the cycle of the device
Multicasting that results in a response.
Allowing users and devices to connect to the network from public or non-dedicated services such
as the internet or dial in services
The ability to limit who can use remote access and what they can do from a remote location

Appendix 93
Service
Remote access
security management
Remote configuration
management
Remote multicast
printing
Remote print
Remote systems
administration
Routing
Routing modeling
Sensor
SMS
SMS Channel
Synchronization
Synchronous Network
Interfaces
System Monitoring
Telephony
Text Chat
Traffic Prioritization
Transmission
Trigger (Initiate)
Tunneled
Transmission
User Directory
Services
User Monitoring
Video Communication
Video management
Voice Channel
Voice Management
Description
The ability to provide authentication and other security mechanisms for remote access
The ability to maintain the configuration of clients that are remotely accessing services or assets.
The ability to send a single print file to a number of remote locations for remote printing
The ability to create hard copy documents in a geographic location that is not where the print file
is generated
The ability to securely manage servers and other assets when not sitting on the console that is
directly attached to the device
Sending traffic over only required network segments to a known address on the other end of the
network links and preventing traffic without valid need from affecting the operation of and/or
being visible to non-required network segments. Limiting the visibility of broadcast messages to
specifically required network segments, based on the header of the broadcast
Routing rules for transporting master data management occurences from master data
management system to local application.
Interrogates and reports real-time readings on a specific physical characteristic (ie temperature,
or a chemical in the air)
The ability to communicate with devices that use the industry standard for short messaging
service in a bi-directional fashion
SMS Channel Service (Short Message Service used for message event notification and simple
interaction services. This is a specific type of Mobile Service).
The capability to manage the synchronization of user authentication and other details to ensure
that information across applications is updated. This is the "Join" Service that allows relationship
management through synchronization and replication.
The ability to do bi-directional handshaking between devices on the network where each step is
acknowledged by the other device on the network
System monitoring based on certain criteria e.g. KPIs.
Support for the standard addressing scheme for telephone handsets to route voice conversations
and other voice encoded traffic over the telephone network
Alpha-numeric information for collaboration and discussion between devices in near real time
Using the header information on IP traffic to determine whether to allow it unlimited, limited or
delayed assess to slower network links
Providing information for routing over an IP network with machine readable headers
Signalize an event to an automated process in the course of the master data management
process.
Provides information for routing over an IP network with external headers, to a specific gateway
address, while encrypting the real headers and information as data
The facility to maintain constituent's name and address register, property registers, supplier
information, etc.
The ability to watch the behavior of any user on the system and determine any behavior that is
outside of the expected or accepted operation of the systems.
Use of moving pictures, normally in near real-time to communicate between two locations
Video management (CRUD)
Voice Channel Services (Delivery and receipt of information through a voice channel including
touchtone, speech recognition, automatic voice response and text to speech services)
Management of voice lines, PBX's, assignments, billing usage, CIT, VRU, etc.

Appendix 94
Service
Voice Recording
Voicemail
Web Services
Description
Recording all voice traffic between specific handsets or telephone instruments
Storage of voice messages that can be played back by users who have access to specific
telephone handset addresses
Provide access to pre-formatted sets of messages and routines that use industry standards for the
exchange of data between parties

Data Management Services are required in all domains of the smart grid. All 7 domains require some
level of data management services, and most required more capability than they have today. The
increase in the volume of data and the tightening of the timing requirements means that most
enterprises that will operate the smart grid will need to evaluate their legacy services for suitability the
future. Data services can be broken down into data acquisition, transformation, persistence and
archiving. Table 26 lists conceptual automation services that support data:
Table 26 Data Management Services
Service
Ad-Hoc Management
Reports
Adapter
Adaptor Matching
Adaptors
Analyse Information
Analysis And Strategy
Application Certification Ecosystem
Application Hosting
Archive Management
Archive Rules
Archiving
Backup And Restoration
Description
This service includes the generation of ad-hoc reports in either electronic or hard copy (e.g.
job log reporting or site statistical reporting.)
Connecting the scheduler to processing nodes
Defines a standard application for connecting to heterogeneous enterprise information
systems, such as ERP, mainframe transaction processing and database systems. The
architecture defines a set of scalable, secure, and transactional mechanisms that describe
the integration of enterprise information systems to an application server and enterprise
applications.
Provides interfaces to Application for the exchange of data between applications.
Analysis tools available for forecasting and analyzing historic data to find patterns etc.
Includes OLAP; modeling.
Analysis tools available for forecasting and analyzing historic data to find patterns etc.
Includes OLAP; modeling.
The ability to successfully complete the testing standards for information devices and
computer systems with in a community of companies that have decided to exchange data
and/or system access and have defined community standards (e.g. Wal-Mart Vendor
Standards)
The process required to run a commercial package for to support business requirements
Manages the archiving of content to external storage. Use of schedule, filters, etc.. In order
to target content for archiving.
Rules for archiving of information, applications, settings, configurations, and system
software for permanent storage.
Permanent or very long-term back up of data on media that is designed to withstand the
long-term storage
Backup and Recovery are key aspects to any information system and consist of both ICT
services and supporting processes. Backup is the activity of copying information from a
system so that it is preserved in case of equipment failure or other catastrophe. Restore is
the activity of restoring a system using the backups of the information and/or systems
applications.

Appendix 95
Service
Backup Management
Business Continuity PreDisaster Services
Calendar Service
Calendaring - Job
Management
Capacity Planning
Cleansing
Cloning
Cold-Starting
Configuration
Connectors
Content Aggregation
Content Guideline
Management
Content Import
Content Load Management
Content Management
Content Publication
Description
The ability to create rules sets that drive the process of backup and restoration of data,
configurations, applications and systems in an enterprise
The operation of the services required to allow for business continuity to be available when
a disaster happens
A system that provides the ability to do timekeeping that defines the beginning and length
and divisions of the year. Also to provide the basis for a scheduling service for activities
The ability to manage a set of activities between a set of systems, such that the desired end
result is achieved in an automated fashion on a regular schedule
The ability to forecast the level of resources that needs to be assigned to a service to
support the anticipated load of the service based on the rules for capacity management
Data cleansing, also called data scrubbing, is the process of amending or removing data in a
database that is incorrect, incomplete, improperly formatted, or duplicated.
The process of saving transactions to a mirror system, as the transactions are processed to
provide a "hot" recovery capability
Whenever a system is being brought on-line for the first time, it must be initialized and
synchronized with the integration infrastructure. The system may be designed to be event
driven, but in order for it to be able to properly process a change to a data item, it must
first be placed in a known initial state. This is true for its internal functions as well as for it
to be able to properly perform its designated services within the context enterprise level
business processes. In case for some reason the integration platform is unavailable,
provisions need to be made for a subset of mission critical functions to be able to function
in a minimally acceptable fashion. For example, it is possible to start up a process that is
completely independent of the integration platform and have a temporary point-to-point
interface. Then, when integration platform is available again, the point-to-point interface
can be disabled. This should be considered only for certain mission critical and mission
important services that rely on each other.
From the integration infrastructure point of view (vs. the application point of view), to the
maximum extent reasonable, a common approach is desired for configuring applications
and data stores into the enterprise environment. When an application interface is initiated
(adaptor or services), it needs to understand the context, environment, and basic
configurations.
Exposure of functionality (application or databases) that enables an application or database
to conduct transactions (CRUD) with the target.
The process of pulling content from a variety of sources and presents it to the user in a
unified format
The ability to create and maintain the rules for loading content and annotation of the
content to maintain consistancy for delivery across channels
The ability to bring content, both structured and unstructured into a document template
Provides the services for loading content and descriptors into the content management
system and documenting the content with additional information to support structured
queries.
The ability to create and maintain the information that is displayed in an interface or into a
hard copy publication for use by customers, employees and other consumers of the
information, and the ability to provide a consistent set of information across multiple
communications channels
The ability to create a packaged view on the content that is available to view by consumers
in any channel (e.g. a printed catalog, a portal, or a sales flyer)

Appendix 96
Service
Content Relationship
Management
Data Access
Data Aggregation
Data Analysis
Data Consolidation
Data Distribution
Management
Data Entry
Data Exploration
Data Export
Data Filtering
Data Flow Orchestration

Data Import
Data Landscape Modeling
Data Life-Cycle Management
Data Management
(Structured)
Data Management
(Unstructured)
Data Mapping Rules
Data Mining
Data Movement
Data Notification
Data Replication
Data Replication
Management
Data Service Discovery
Data Service Registration
Data Store Integration
Description
Manage the rules that link rich content (text, video, image, ) to a product template
The ability to reach into organized data repositories and retrieve the information that is
useful to answer the query that is being asked
The ability to move (or link) data from many systems into a meaningful single repository
(physical or virtual) to allow data mining
The ability to look at each piece of data in context and determine the quality of the data
and the value of the data to the enterprise
Bringing data from several databases instances together into a single instance using a key
structure between the databases
The ability to create and maintain rules about what data will be sent to which locations and
what the restrictions are on the sending (or receiving) of the data
The ability to enter data via an interface (e.g. keyboard, microphone, scanner, etc) into a
digital format for storage in an information system
The ability to create parameters for data mining. Data mining is the collection of large
amounts of data from one or more repositories. Once a useful connection is developed, the
resulting rules are moved to production data mining
The ability to move data out of a structured data store
Filter out certain data from the local applications during selection. The service will use role
definitions to identify the receiver user of the data and to filter from the local application
on this basis.
To define and manage and monitor complex data flows across the system.
The ability to bring data into a structured data store
Modeling of local and master data management application and system landscape (logical
and technical).
Maintain and delete services with a private or public registry during the full lifecycle of the
service (creation, maturation, aging, retirement).
Storage of structured data is normally within a database management system (DBMS),
often a Relational Database Management System.
The ability to create and maintain document and image stores which are organized in a
fashion to allow a user with some familiarity to retrieve the right documents
Mapping rules between master data management object model and the local application
obejcts models. Input for Inbound and Outbound Mapping.
Data Mining is the specific investigation of data in a warehouse looking for new and useful
connections that will provide insight into marketing and other activities.
The ability to move data from one repository to another repository in an automated and
scheduled fashion
Signalize an event to a user in the course of the master data management process.
The ability to replicate changes in data to various identical data stores either local and/or
distributed
Creation and maintenance of the rules that allow for orderly replication of data from both
un-tethered systems and enterprise systems
To discover existing data management services.
To register in a private or public registry during the full lifecycle of the service.
The ability to transform data at the transaction level for movement of the transactions or
records between two or more structured data stores

Appendix 97
Service
Data Transformation
Data Update
Data Validation
Data Warehousing
Database Management
Decision Support
Defined Management
Reports
Delay Notification
Digital Media Production

EDI
EIS (Executive Information
System)
Electronic Publishing
Encrypted Data For

Communication
Encrypted Data For Storage
Description
The ability to change the format of the data elements from one system to support the
operation on those data elements by another system or for delivery to another system or a
user (e.g. changing Euros to dollars, or English to Chinese, or taking a short integer and
making it an integer)
Services for creating, updating and deleting data, whether the data is retained by an
application, persistent data store or some other means. These services are responsible for
ensuring updates to this data are performed in accordance master data management
services, including data replication performed for performance reasons. The quality of the
data and confidence level of the accuracy of the data is indicated. The golden record will
have a quality of data measure while an unsanctioned copy would be expected to have a
much lower data quality rating. Regarding data currency, there is typically a metadata field
that gives an indication of either when the data was updated (time stamp) or how long
since the data has been updated (age indicator).
Data Validation Services are both those services tht allow data validation within a database
management system or with external services for example reference data or external
services such as Postal Address Files (PAF)
The ability to combine disparate data from disparate systems into a single data store with
valid relationships for the purposes of data mining and reporting. Normally done overnight
or once a week to give a historical view
Secure, structure, maintain, log and provide access to electronic data in support of
distributed and or localized processing
Maintenance and summarization of data using pre-determined rules to provide information
supporting rapid decision making.
This service includes the generation of defined reports in either electronic or hard copy
(e.g. job log reporting or site statistical reporting.)
This service is responsible to notify the consumer through a channel (might be a prefered
channel) of delay in regards of one or multiple services he is "registered" to (like a flight
delay for instance).
The ability to create digital content for display to an audience (e.g. employee training, sales
promotion, professional production) the content could be video, audio, textual, etc
The ability to use exchanges standards for moving data between systems or enterprises in
electronic form. The standards include but are not limited to OFX, UNEDIFACT, etc.
Executive Information System (EIS) software component provides you with a powerful, yet
simple tool that allows you to view and analyze key factors and performance trends in the
areas of sales, purchasing, production, and finance. The executive information system
allows you to see both summary and detail level data. You can display summarized data
that reflects the overall status of your enterprise. EIS spotlights areas that need attention
before situations become critical and costly by highlighting key performance indicators. You
can use drill-down capabilities to trace problem areas to any level.
The ability to create complex compound documents for distribution either in electronic
form or in hard copy - document templates may be setup to be automatically completed
with component data on a scheduled basis
Encryption of data within the boundaries of a communication method. This would cover all
of the transport methods including those that use a persistent data store such as the file
storage mechanism found in many store and forward paradigms while still clearly
delineating the boundaries between a persistent data store and the transport mechanism.
Encryption of data within data repositories. This covers the encryption of data governed by
applications using file system and database formats as well as other persistent data stores
not associated with data transport mechanisms.

Appendix 98
Service
Enterprise Rollback
Event Scheduling Service
Exception Handling
Extract/Transform/Load
Extraction
Fee Management
File Services
File Sharing
Global Setting Management
Governance Services
Grid
Grid Management
Implementation And
Controls Set-Up
Inbound Data Mapping
Indexing & Referencing
Information Integration
Information Management
Description
The ability to rollback an update or change to information contained in multiple systems
and databases in a coordinated and automated fashions
The ability to create and maintain a schedule of events that should be automatically
intiated and terminated in the enterprise
From an integration infrastructure point of view, it is helpful if exceptions are presented in
a consistent manner. Exceptions can be divided into at least two categories: system and
functional. Systems exceptions are those generated as the result of program and/or
hardware system failure. Functional exceptions are those generated as the result of data,
business process, or logic errors. Each category can be further classified as fatal, warning,
and information only. This service is also often linked to the enterprise system
management and monitoring service for process.
Services to extract data from existing data sources, transform the data (into the required
input format) and then load the data, in a highly efficient manner, into the destination
database.
Mechanisms for transferring relevant data from local systems to the master data
management environment. Master data instances are retrieved from the local systems.
Selection is based either on predefined rules or based on the authorization level of the
user.
Assessment of rates and fees required for an application
Maintain and provide access to files in a file system
The ability to allow and restrict users and systems access to specific unstructured
documents with in the enterprise based on rules, permissions, and authorization
The ability to create and maintain the overall setting for all users of a service or for how the
service will behave
To manage the life cycle of a data items; Define and track chain of custody, versioning, etc.
This capability provides the necessary checks before a message is published, during system
integration and also on a continuing basis for B2B situations. Validation rules on message
syntax, data integrity, and business logic conformance can be developed and implemented
as a service to be executed by the adaptor layer. Any exceptions raised by this service will
determine whether the data can be published or not.
The ability to create a virtualized server farm, where services run based on rules that
determine how many resources are devoted to each service.
The ability to create and maintain the rules for the prioritization of use of the resources by
the rules
Configuration, Set-up of seed data, business rules , business defined criteria that govern a
service or application
Association of meta data definitions and conversion rules between local application data
models and the master data management data model.
The Indexing & Referencing (I&R) service maps application specific identifiers to and from
global identifiers at each interface. It generates unique identifiers for messages and/or
objects for canonical message data and is responsible for storing the transformation
mappings persistently. These identifiers establish a unique reference between an
application message and its corresponding canonical message data, thus enabling the
decoupling of sources of data from consumers of data.
The ability to bring information into a single view for data mining or business analysis
The ability to manage the information in the enterprise across all platforms and services to
maintain the health of the data stores

Appendix 99
Service
Job And Process Queue
Management
Job Restart
Knowledge Indexing
Knowledge Repository
Knowledge Searching
Management Reports
Management & Monitoring
Master Data Management

Services
Message Creation
Message Execution
Message Explosion
Message Queue
Messaging Persistence
Metadata Management
Modeling
Description
Job queue management functions - management of the machine assets that are assigned to
a specific job or process, including launch and termination time, priority slices on hardware,
prioritization of access to data stores, spawning additional copies of processes and
trimming the resources that are allocated to the process as higher priority processes enter
the queue
Restart of an automated processing job after a failure has occurred. Either restart from the
beginning of the job, or from an identified restart point.
The ability to index the content of unstructured knowledge objects, both within the
enterprise and in locations in the enterprise and the extended partner network for future
query
The ability to consolidate key unstructured documents from many sources, including
individual user devices into an enterprise data store, to provide a higher level of availability
and consistency to the queries of the authorized users
The ability to query one or more knowledge indexes for information that is relevant to the
query being performed, normally the service includes the ability to rank the results based
on the match to the query
This service includes the generation of defined and ad-hoc Management reports.
A middleware platform is often linked to an enterprise system management tool, but now
done using consistent semantics. Systems and/or functional exceptions that require the
attention of appropriate people can be sent electronically. Related information is logged
for auditing, diagnosing, processing, and manual interventions.
A system of record is an information storage system which is the data source for particular
data elements and information sharing sets (e.g., message payload). A service should only
be allowed to modify items for which it is the system of record. To achieve the desired
benefits of COTS, data replication will be unavoidable (vs. customizing off-the-shelf
packages to obtain data from a central database). Therefore, the integration infrastructure
must ensure that there is only one system of record for each piece of information at any
given time. It is possible to dynamically change the system of record via chain of custody
management, but this ability may not be worth the tradeoff of increased integration
infrastructure design and implementation complexity.
Creation of a machine readable header to wrap information in, so that it can be transmitted
between devices on the network
Identifies the message types and formats the incoming message. Common Service that
passes managing the steps needed to get a message from source to destination. Uses
Messaging, Transaction, Network and/or Process Management services.
The ability to automatically route a message to more than one internal service or addressee
A facility that ensures that a message is delivered to its target, includes message ordering
and prioritization.
This capability provides for archiving the messages for auditing, workflow, and business
intelligence purposes. Typical integration solutions support the internal needs for message
persistence for auditing and workflow, but may not have a way to provide business
intelligence on top of messaging. Message persistence, in conjunction with the Indexing
and Referencing service, are fundamental to establishing event histories and reporting
capabilities that transcend individual systems.
Mechanisms for the configuration and maintenance of predefined settings for the master
data objects, application landscape, and master data object mappings/routing. It has
services to model and define procedures and rules.
Setup and utilization of complex analytics that will automatically review records, based on a
set of rules to determine trends in the records that can be displayed to users

Appendix 100
Service
Multi-Media
Multi-Media Chat
Multi-Tasking
Multiprocessing
OLAP (On-Line Analytical
Processing)
OLTP (On-Line Transaction

Processing)
Operational Data Store
ORB (Object Request Broker)

Platform Management
Portal Management
Portal Page Creation

Portal Pages Framework
Purging
Query Management
Recovery
Replay
Resource Adapter
Restart Management
RFID
Roll Back
Schedule
Searching Directory
Description
Integrated graphics, audio, video, and text
The ability to use text, video, audio and other media formats for on-line discussions and
collaboration in near real time
The ability to have a single device handle multiple services simultaneously thru a single
physical pipeline
The ability to break up a stream of work and have it handled across a number of physical
devices
Decision support software allowing the user to quickly scrutinize information summarized
into multidimensional views and hierarchies. OLAP included the use of multidimensional
models to represent complex data relationships, using slice and dice to look at
information from different viewpoints.
The ability to take records from users and services one record at a time, provide validation,
route error condition messages back to the creator and store the valid transactions or
invalid transactions with error messages in a structured data store
The ability to create and maintain information across traditional applications and data
stores in a single data store to support use of the data by multiple systems. An ODS is an
operational version of a data warehouse and is normally up to date with the movement of
data in the enterprise
The ability to orchestrate the services request for information from other services or data
stores and manage the process of the exchange
The ability to monitor and manage the hardware platform the infrastructure is built upon
The Management activities of the Portal Application, includes selection of standard alerts,
indexing and monitoring of criteria (based on set-up). Also includes capabilities such as
caching and pooling.
The capability to build Portal Pages based on either Framework Templates or algorithm.
These pages will be served to the various channels and may utilize common services.
The templates provided within Portal Products to assist in the formulation of consistent
look and feel for Portal Content Pages
The process of verification of data on archival media and the subsequent removal of data
from the primary storage media
Handling all requests for information or data from a specific data store - requests can be
handled on a priority basis and they can be interleaved with other processes based on
assigned priorities
Transfer of information from a backup media to a specific system with a specific
configuration for operation then loading it with a specific set of data based on an agreed to
time and date
The reinstating of an event upon failure
Prepackaged modules that provide connectivity and or transformation between
applications and databases.
The ability to determine the state of an ICT process and if it has stopped, return the process
to operation from the point it stopped at, or at the beginning of the current step or record
Locating and identifying packages by utilization of location device(s)
Retraction database changes to a specific previous date and time or to the beginning of a
logical transaction
Time-based execution of a formalized chain of master data management events.
The querying of Portal databases to find data (e.g. users, groups, authorizations) based on
the search criteria, from the Directory

Appendix 101
Service
Searching Other Databases
Semantic Model
Management Services
Staging
State Management
System Directory Services
System Management
Tracking
Transaction Controls
Transaction Management
Transaction Monitoring
Transaction Rules
Trigger Workflow
Version Management
Voice Input Processing
Workflow Services
Description
The querying of other databases to find data (e.g. media, information) based on the search
criteria, from the Portal Product
To ensure semantic consistency across all interfaces independent of technologies employed
and vendor products used, these services enable use of artifacts (e.g., schemas for
messages, schemas for persistent data stores, etc.), derived from the semantic model
across all nodes and all layers.
Store & forward master data instances across its entire life-cycle.
Determine the status of an master data instance being processed and initiate and
determine the workflow based on this status.
The ability to provide system to system addressing in the network to allow users and
services to connect to authorized services and authenticate
Management of the computing platforms including: load monitoring, capacity, software
distribution, and configuration control of the desktop systems and servers
Service to analyze the audit trail in order to reconstruct past events.
Configuration, Set-up of seed data, business rules, business defined criteria that govern the
ERP General Ledger Module.
Processing of data across multiple databases.
Monitoring of the transaction to determine if it is successful or not (passes message back to
Message Execution Service). Includes the use of two phased commits, multiple targets and
distributed transactions.
Rules specific to the target databases e.g. cascade update, two phase commit.
A call to a workflow component when user intervention is required for an event (within an
event flow).
Manages the various version of rich content, check-in, check-out, etc.
Conversion of audio information to digital information that can either be recorded as
textual data, records, or machine commands
The set-up and running of processes to control document flows including escalation, email
notification, task management, prompts and reminders

Appendix 102
Appendix D. Roadmap & Maturity Model

Policy Timeline
Figure 47 depicts a typical policy timeline for a California utility. Each utility should employ a similar
diagram to identify deadlines set by federal, state and local regulatory and legislative bodies. This
timeline provides high level input to the utility Smart Grid development roadmap.
Figure 47 - California Smart Grid Policy Timeline (Southern California Edison, 2010)
Pursuing the Smart Grid Vision

A high-level development roadmap for the smart grid identifies the technologies a utility should plan
to pursue over the course of the next two decades in order to make its smart grid vision a reality. The
smart grid will evolve in complexity and scale over time as the richness of systems functionality
increases and the reach extends to greater numbers of intelligent devices.
Most utilities will create and follow development roadmaps, which tend to have several major stages.
Within each development roadmap stage, there are two activity portfolios to be managed
simultaneously. The smart grid deployment project portfolio consists of smart grid technologies
commercially ready for deployment. The technology evaluation portfolio includes initiatives to
identify, evaluate, and test emerging technologies expected to be deployed at a later stage. Figure 48
illustrates the distinction between these two portfolios in terms of technology maturity over time.
Roadmap & Maturity Model

Appendix 103
Figure 48 - Smart Grid Project Portfolios as a Function of Maturity (Southern California Edison, 2010)
Technology evaluation portfolio projects fall into the Leading Edge areas of the maturity curve. These
projects require further evaluation of emerging technologies to better understand the capabilities such
technologies could contribute to the smart grid vision, their progress towards technical maturity, and
the corresponding value that they might unlock.
Smart grid deployment portfolio projects, on the other hand, involve the planning and execution of
deployment plans for commercially available smart grid technologies. Although these technologies
have crossed the chasm of the maturity curve, given the urgency of state and national policy goals they
increasingly fall within the Early Majority or later areas of curve. Historically, most utilities have
preferred to adopt technology later in the maturity lifecycle, allowing for greater confidence in
implementation and operation. Earlier adoption and adaption indicates that significant project risks
could be substantially mitigated through an effective technology evaluation process
A four stage roadmap structure is recommended for smart grid transformations. In this model, the four
stages of the smart grid development roadmap and high level plans for deployment and technology
evaluation projects to be included within each stage are:
Stage 1: Foundation (past work)

Comprised of already completed foundational work for the deployment of advanced measurement and
control systems, this is a preliminary period where many utilities get early experience with new

Appendix 104
technologies such as wide-area measurement and control systems - smart meter deployments were
initiated by a number of utilities during this stage.
Stage 2: Inform and Automate (near-term)

In this stage most utilities focus on the following areas:
Evaluation of energy storage
Integration of renewable and distributed energy resources
Development and interoperability testing of home area network devices and vehicle charging
equipment
Ongoing development of interoperability and cyber-security standards
Electric system studies and engineering analysis regarding operational impacts from dynamic
resources, bi-directional distribution flows and new operating paradigms
Workforce safety and productivity technologies
A number of North American Smart Grid pilot projects, many funded by the American Recovery and
Reinvestment Act (ARRA), will commence during this period. Efforts to educate the general public on
Smart Grid topics should also gain traction during this time.
Stage 3: Interactive (mid-term)

This stage focuses on technologies that leverage prior investments and involves retrofit work. The aim
is to begin the process of building Grid 2.0. The anticipated evolution from Grid 1.0 to Grid 2.0 is
depicted in Figure 49 for a variety of grid characteristics. Grid 2.0 fully automates the energy delivery
system across the entire value chain with increased interactions among smart grid devices, the utility,
and customers. It has both hard grid assets (advanced energy storage, super-conducting equipment),
and soft grid assets (next-generation computing and analytics systems) to glean the full value of the
new grid for utility customers. Several documents, including Grid 2.0: The Next Generation (Willis,
2006), suggest Grid 2.0 will be fully decentralized. By 2030, a highly interactive and hybrid grid will
include large central resources and substantial decentralized supply and demand resources. This is
analogous to 2011 hybrid information networks linking large centralized data centers, cloud
computing, highly distributed personal computing, and smart phones.

Appendix 105
Figure 49 - Grid 1.0 Evolution to Grid 2.0
This renewed electric system will enable seamless integration of large renewable and distributed
generation resources. It will also facilitate the integration of energy storage technologies to support
state and federal legislation and policy goals such as greenhouse gas reductions, Renewable Portfolio
Standard (RPS) and electric transportation initiatives. Grid 2.0 incorporates the next generation of
broadband wireless and field area telecommunications technologies to support high speed, low latency
information exchange among highly distributed devices. Smart grid efforts will merge advanced data
analytics and intelligent systems into existing grid control systems, resulting in a complex system-ofsystems to provide integrated grid control and ubiquitous, real-time grid-state information. As a result,
opportunities will emerge to reliably link customer demand response and other smaller distributed
resources into wholesale market operations with the requisite ability to coordinate operational dispatch
between wholesale market objectives and distribution grid objectives.
Stage 4: The Intuitive and Transactive Grid (long-range)

The 2030 decade will see continued deployment of Grid 2.0 capabilities across most utility systems and
the introduction of highly distributed intelligent controls involving machine-to-machine transactions.
This stage of the smart grid development roadmap assumes full convergence of information and
energy systems, as well as continued breakthroughs in computing architectures, cyber-security,
internet technologies, autonomous multi-agent control systems, artificial intelligence applied to electric
system operations, wireless telecommunications, energy storage, power electronics, energy-smart
consumer devices, consumer information technology and sensing technologies. Results should include
wider deployments of distributed computing technologies for faster system response times, the
integration of many more sensory and control nodes at the distribution and customer levels, and the
ability to manage and precisely react to supply and demand imbalances at the micro level or through
aggregation at any level or nodal point across the transmission and distribution grids.

Appendix 106
Maturity Model
To move forward with a smart grid transformation, a utility should assess its current state and then
define its own roadmap and strategy for achieving the desired functionalities. This section presents an
industry-standard methodology to help utilities plan smart grid implementation, prioritize options,
and measure progress.
The Smart Grid Maturity Model (SGMM) was developed by electric power utilities for use by electric
power utilities. It is under the stewardship of the Software Engineering Institute at Carnegie Mellon
University. The SGMM is a framework for understanding the current state of smart grid deployment
capabilities within an electric utility. It also serves as a context for establishing future strategies and
work plans pertinent to smart grid implementations. The model is comprised of eight domains, each
containing six levels of maturity.
Implementation of a Smart Grid involves major technological transformations to enable seamless
communications among grid components and systems to fulfill the required capabilities. Electric
utilities executives and senior leaders must understand the potential impacts these technological
transformations will have on their existing organizational structure. This is critical because:
1. A typical utility ICT infrastructure is currently somewhere between The Silo Architecture and the
Integration using Enterprise Services Buses in the range of System-of-Systems Design patterns
(Appendix A),
2. To satisfy long-term Smart Grid capabilities, a utility must move to an architecture allowing any
system to interact with any other system, and
3. Fundamental changes to how a utility operates are necessarily disruptive.
Utilities can use their SGMM level assessment to start discussions among their functional domains on
the potential organizational transformations needed to ensure Smart Grid success. It also provides a
context for the new technologies in terms of prosumer energy control, and utility grid efficiency
improvements for cost containment.
For more information about the Smart Grid Maturity Model, the reader is encouraged to visit the
Software Engineering Institute website: http://www.sei.cmu.edu/smartgrid

Appendix 107
NOTES

Appendix 108
Appendix E. Glossary of Terms

The Smart Grid Today glossary (SmartGridToday) is an additional source for the quizzical reader,
should any desired acronym or term not be in Table 27.
Table 27 - Glossary
Term
Meaning
1 GigE
AAA
AC
ACL
ADR
AMI
BAAM
BEC
BP
BPEL
BRE
CDM
CEA
CEP
Choreography
CIM
CIP
CLI
Comms
COMTRADE
COTS
Gigabit Ethernet see BEC

Authentication, Authorization, Accounting - acronym used in computer/information security to describe
protocols supporting these attributes (RADIUS, Diameter, TACACS, etc.)
Alternating Current electric power in which the movement of electric charge periodically reverses
direction. See DC.
Access Control List - typically a list of permissions attached to an object in a computer file system
Automated Demand Response - the ability to manage customer consumption of electricity in response to
supply conditions
Advanced Metering Infrastructure - electric utility equipment needed to install, use, and manage Smart
Meter with real-time sensors, power outage notification, and power quality monitoring
Behavioral Awareness and Monitoring - heuristics used to detect abnormal or threatening human
behavior patterns
Gigabit Ethernet Channel a communications channel for Gigabit Ethernet (GbE or 1 GigE) technologies
for transmitting Ethernet frames at a rate of a gigabit per second
Basic Profile - see WS-I BP
Business Process Execution Language - an OASIS standard for specifying business process actions via web
services. BPEL processes export and import information exclusively through web service interfaces (also
known as WS-BPEL)
Business Rules Engine - a software system executing one or more business rules in an ICT production
environment.
Canonical Data Model - a design pattern used to communicate between different data formats
Customer Experience Analytics - software used to identify and analyze customer behavior patterns within
and across multiple access points.
Complex Event Processing - a computing technique used to process action messages from all
organizational layers by identifying those most meaningful, analyzing their impact, and taking subsequent
action in real time
See Process Choreography
Common Information Model - an electric power industry standard officially adopted by the IEC to allow
application software information exchange
Critical Infrastructure Protection - the preparedness and serious incident response involving the critical
infrastructure of a region or nation
Command-line interface - provides interaction with software by typing commands to perform specific
tasks (instead of WIMP - see GUI)
Communications this substitution is widespread in casual conversation and technical writing
COMmon format for TRAnsient Data Exchange for power systems - an IEEE file format for oscilloscope
data.
Commercial Off-The-Shelf - computer systems developed and marketed by commercial software vendors
Glossary of Terms
Appendix 109
Term
Meaning
DA
DC
DER
DMS
DNP3
DoE
DR
DSM
EDI
EDM
EIM
EIS
EMS
ESB
ESM
FACTS
FAN
FIPA
FIPS
Publications
Firewall
FISMA
FLISR
GbE
GDA
GES
Distribution Automation a broad set of capabilities in the utility distribution system, including control
center-based SCADA, distribution management system, substation automation, primary and secondary
network automation, associated smart controls, etc.
Direct Current electric power in which the electric charge flows in one direction. See AC.
Distributed Energy Resource a small energy source, typically producing power near where the power is
used (very little power transmission or distribution between generator and power consumer)
Distribution Management System - a system used by electric utility grid operators to manage distribution
system performance
Distributed Network Protocol - communications protocol used between process automation components
(used by SCADA systems)
U.S. Department of Energy - a Cabinet-level U.S. government department with executive authority on
energy and nuclear material handling policies
Distributed Resource see DER
Demand Side Management - the modification of consumer demand for energy through financial
incentives, education, electronic devices, and other means (also known as Energy Demand Management)
Electronic Data Interchange - the structured transmission of data between organizations by electronic
means.
Energy Demand Management - see DSM
Enterprise Information Management - optimizes use of information within organizations, for instance to
support decision-making or day-to-day operational processes requiring availability of knowledge by
managing information on an enterprise level.
Executive Information System - a type of information system used to facilitate and support the decisionmaking needs of senior executives
Energy Management System - a system of computer-aided tools used by electric utility grid operators to
manage generation/transmission system performance
Enterprise Service Bus - a software architecture construct with fundamental services for complex
architectures via an event-driven and standards-based messaging engine
Enterprise Semantic Model - the logical representation of enterprise information assets used to manage
or facilitate business processes.
Flexible AC Transmission Systems application of solid-state switches, coupled with capacitors, used to
simultaneously regulate transmission voltages, fine-tune reactive power and remove noise from the AC
signals. FACTS are important enablers of variable energy generators (wind, solar).
Field Area Network a communications network typically with wide geographical coverage and low to
medium bandwidth, depending on the needs of specific use cases
Foundation for Intelligent Physical Agents - an IEEE standards organization developing and setting
computer software standards for heterogeneous, interacting agents and agent-based systems
Federal Information Processing Standards (FIPS) Publications - a series of documents for the U.S. Federal
government issued by NIST
Device or set of devices controlling propagation of network transmissions based upon a rule set.
Federal Information Security Management Act of 2002
Fault Location, Isolation and Services Restoration
Gigabit Ethernet see BEC
Generic Data Access - an IEC 61970-40X GID interface used for model management, access, and update
distribution
Generic Events and Subscriptions - an IEC 61970-40X GID interface used for pub/sub of generic XML
messages
Glossary of Terms
Appendix 110
Term
GID
GOOSE
Grid 2.0
GSE
GSSE
GUI
HAN
HEC
HSDA
HVDC
ICT
IEC
IED
IEEE
Internet
IP
IPS
IRM
IRM
IT
ITU-T
IVR
JPA
JSON
MAC
Meaning
Generic Interface Definition - a set of common services used for enterprise integration by utilities; part of
IEC 61970 standard
Generic Object Oriented Substation Events - control model mechanism to package any data format into a
data set and transmit within 4 millisecond - one of two subdivisions of GSE
See Smart Grid
Generic Substation Events - a control model defined by IEC 61850 providing a fast and reliable mechanism
to transfer event data over entire substation networks
Generic Substation State Events - an extension of event transfer mechanism exchanging only status data
using a status list (string of bits) rather than a GOOSE dataset
Graphical User Interface - allows interaction with an electronic device through the use of images (utilizes
WIMP instead of CLI)
Home Area Network - communications network for customer's home - see PAN
HDMI Ethernet Channel technology consolidating video, audio and data streams into a single HDMI
cable
High Speed Data Access - an IEC 61970-40X GID interface used for access to real-time measurement data
High Voltage Direct Current an electric transmission system using direct current for the bulk
transmission of electrical power. Over long distances, HVDC is expected to be less expensive, with lower
electrical losses compared to a similar alternating current system.
Information and Communications Technology - an extended synonym for ICT stressing the role of unified
communications in modern information technology
International Electrotechnical Commission - a non-profit, non-governmental international standards
organization which publishes International Standards for electrical and electronic technologies
Intelligent Electronic Device - a microprocessor-based controller of power system equipment, such as
circuit breakers, transformers, and capacitor banks.
Institute of Electrical and Electronics Engineers - a non-profit professional association dedicated to
advancing technological innovation related to electricity
A global system of interconnected computer networks using IPS
Internet Protocol - the principal communications protocol used for relaying packets across a network
using the Internet Protocol Suite
Internet Protocol Suite - the set of communications protocols used for the Internet and similar networks.
Also known as TCP/IP, from two of the most important IPS protocols: the Transmission Control Protocol
(TCP) and the Internet Protocol (IP)
Interface Reference Model (IEC 61968-1) provides the framework for identifying information exchange
requirements among utility business functions
Institute of Risk Management - a leading international professional education and training body for risk
management
Information Technology - any microelectronics-based collection of computing and telecommunications
capabilities designed to acquire, process and disseminate textual, numerical, and non-structured
information. See ICT.
Telecommunication Standardization Sector, part of the International Telecommunication Union (ITU)
based in Geneva, Switzerland.
Interactive Voice Response technology allowing computer-human interaction through the use of voice
and keypad inputs.
Java Persistence API - a Java programming language framework managing relational data in applications
JavaScript Object Notation a lightweight data-interchange format
Media Access Control Layer
Glossary of Terms
Appendix 111
Term
Meaning
Mashup
ML
MoM
MOM
MultiSpeak
NERC
NERC-CIP
NETL
NIST
NISTIR 7628
NRECA
OASIS
OFX
OLAP
OLTP
OMG
OMS
OPC
Orchestration
OSGi
OSI model
P&C
PAN
PCC
PHY
PKI
PLC
PMI
A web application that combines data and/or functionality from more than one source, sometimes called
a web application hybrid
Management Layer one of four smart grid management types (Element, System, Services, Smart Grid)
Manager of Managers a smart grid construct to support distributed grid management services
coordinated by a single component, called the Manager of Managers
Message-Oriented Middleware infrastructure used to send and receive messages between distributed
systems.
A specification defining standardized interfaces between software applications commonly used by electric
utilities
North American Electric Reliability Corporation - a nonprofit corporation promoting the reliability and
adequacy of North American bulk power transmission
See CIP
National Energy Technology Laboratory - a science, technology, and energy laboratory operated by DoE
National Institute of Standards and Technology - a measurement standards laboratory operated as a nonregulatory agency of the United States Department of Commerce
Guidelines for Smart Grid Cyber Security issued in August 2010 as an Interagency report (NISTIR) by the
United States Department of Commerce, National Institute of Standards and Technology (NIST)
National Rural Electric Cooperative Association - an organization representing over 900 electric
cooperatives in the United States
Organization for the Advancement of Structured Information Standards - a global consortium supporting
the adoption of e-business and web service standards
Open Financial Exchange - a data-stream format for exchanging financial information
On-Line Analytical Processing - a business intelligence approach used to swiftly answer multi-dimensional
analytical queries
On-Line Transaction Processing - a class of systems used to facilitate and manage transaction-oriented
applications
Object Management Group - a consortium focused on modeling programs, systems and business
processes
Outage Management System - a computer system used to restore power by operators of electric
distribution systems
OLE for Process Control - an open standard used by GID
See Process Orchestration
Open Services Gateway initiative - a Java service platform implementing a complete and dynamic
component model, characterized by "bundles" of functionality
Open Systems Interconnection model - a sub-division of network communications into seven smaller
parts - each layer is a collection of similar functions providing services to the layer above it and receives
services from the layer below it
Production and Control
Premises Area Network - communications network for grid customer, more generic than HAN
Point of Common Coupling see PoCC
Physical Layer - the first and lowest layer in the seven-layer OSI model of computer networking.
Public Key Infrastructure - the set of assets needed to create, use and manage digital certificates
Programmable Logic Controller a small industrial computer used to replace relay logic. A PLC is similar
to RTU, but is typically easier to program. RTU and PLC technology are slowly merging. See RTU for detail.
Privilege Management Infrastructure - supports a strong authorization system via the management and
use of privileges
Glossary of Terms
Appendix 112
Term
Meaning
PMU
PoCC
PQ
PQDIF
Process
Choreography
Process
Orchestration
PubsFIPS
QoS
RBE
RDF
RMS
RPC
RPS
RTU
SAML
SCA
SCADA
SCAP
SDO
SDO
SED
SEP-2
Service
Choreography
Service
Orchestration
SGAC
Phasor Measurement Unit - a device designed to measure the electrical waves on an electricity grid to
determine the health of the system
Point of Common Coupling the place to which a collection of DER (DR) connects to the
Power Quality - the set of electrical property limits allowing electrical systems to function in their
intended manner without significant loss of performance or life.
Power Quality Data Interchange Format - a binary file format (specified in IEEE Std 1159.3-2003) used to
exchange voltage, current, power, and energy measurements between software applications
A form of service composition in which interactions between partner services are defined globally. At runtime each participant executes according to other participant behaviors with no central control
The process of coordinating an exchange of information through web service interaction. Orchestration
typically is guided at runtime by a central control mechanism.
See FIPS Publications
Quality of Service - a computing mechanism providing different execution priority rankings to different
computing objects (e.g. users, destinations, applications, data types, data flows). It also can be used to
guarantee a certain level of performance to a data flow
Report By Exception information is transmitted only when a pre-defined threshold or condition is
reached. RBE reduces communication traffic and subsequent data handling.
Resource Description Framework - a general-purpose language for representing information in the Web.
Root Mean Square - a measure of the magnitude of a varying signal
Remote Procedure Call - an inter-process communication allowing software to cause the execution of a
procedure in another address space without coding the remote interaction
Renewable Portfolio Standard a regulatory mandate to increase energy production from renewable
energy sources (wind, solar, biomass, geothermal).
Remote Terminal Unit or Remote Telemetry Unit an electronic device interfacing field devices to a
distributed control system (i.e. SCADA). Similar to PLC, but typically preferred where communications are
difficult. RTU and PLC technology are slowly merging. See PCL for more detail.
Security Assertion Markup Language - an XML-based open standard for exchanging authentication and
authorization data between security domains
Service Component Architecture - a programming model for building applications and solutions based on
a Service Oriented Architecture
Supervisory Control And Data Acquisition - industrial control systems, computerized to monitor and
control commercial and infrastructure processes
Smart Grid Conceptual Architecture Project - the Smart Grid conceptual reference model for which the
SGAC is responsible
Service Data Objects - a technology allowing heterogeneous data to be accessed in a uniform way.
Standard Developing Organization - an organization with the scope of establishing national, regional or
international engineering standards
Smart Electronic Device used interchangeably with IED (Intelligent Electronic Device)
Smart Energy Profile 2.0 - an open standard for implementing secure, easy-to-use wireless home area
networks to manage energy consumption
See Process Choreography
See Process Orchestration
Smart Grid Architecture Committee - responsible to the SGIP for creating and refining a Smart Grid
conceptual reference model, including lists of the standards and profiles necessary to implement the
vision of the Smart Grid
Glossary of Terms
Appendix 113
Term
Meaning
SGIP
SGMM
SIP
SLA
Smart Grid
SOA
SOAP
SoS
SQL
SSL
SSO
SSO
STATCOM
THD
TLS
TSDA
UDDI
UN/EDIFACT
VAR
VOIP
Volt/VAR
VPN
VPP
W3C
WAN
Web
Web 2.0
Web Service
Smart Grid Interoperability Panel - a stakeholder organization administered under a NIST contract to
identify, prioritize and address new and emerging requirements for Smart Grid standards
Smart Grid Maturity Model a management tool used to help plan a smart grid implementation,
prioritize options, and measure progress (maintained by the Software Engineering Institute at Carnegie
Mellon University)
Session Initiation Protocol - an IETF-defined signaling protocol used to control multimedia communication
sessions (VOIP, etc.)
Service Level Agreement a service contract formally defining expectations, usually based on response
times, between a customer and a service provider.
A utility power distribution grid enabled with computer technology and two-way digital communications
networking.
Service-oriented architecture - a set of design principles aimed toward packaging functionality as a suite
of interoperable services, residing in multiple systems, and usable by many business domains
Simple Object Access Protocol - a protocol specification for exchanging structured information via web
services
System of Systems - a collection of task-oriented or dedicated systems with pooled resources and
capabilities to create a more complex 'meta-system' offering more functionality and performance than
the sum of the constituent systems
Structured Query Language - a database computer language designed for managing data in relational
database management systems (RDBMS), and originally based upon relational algebra and calculus
Secure Sockets Layer - a network protocol succeeded by Transport Layer Security (TLS)
Single Sign On - a property of access control of multiple related, but independent software systems
allowing a user to log in once and gain access to all systems without additional log in prompts
Standards Setting Organization - an organization promulgating or maintaining standards
Static Synchronous Compensator a regulating device on AC electricity transmission networks, acting as a
source or sink of reactive AC power on the electrical network. See FACTS.
Total Harmonic Distortion - an inverse measurement of the fidelity of a signal to its source
Transport Layer Security - a network protocol and successor to Secure Sockets Layer (SSL)
Time Series Data Access - an IEC 61970-40X GID interface used for access to historical measurement data
Universal Description, Discovery and Integration - a platform-independent, XML-based registry for
businesses to be listed on the Internet, including a mechanism to register and locate web service
applications
United Nations/Electronic Data Interchange For Administration, Commerce and Transport - an
international EDI standard
Volt-Ampere Reactive - a unit used to measure reactive power in an AC electric power system
Voice Over Internet Protocol - technology used for the delivery of voice communications and multimedia
sessions over an Internet Protocol network
Used to express the need for careful management of the interaction between voltage and VAR control.
Virtual Private Network
Virtual Power Plant a collection of distributed generation managed by a central entity (aggregator)
World Wide Web Consortium - an international standards organization for the World Wide Web
Wide Area Network
See WWW
A loosely defined set of web applications characterized by collaboration, user-defined design,
participatory information sharing, and standards-based interoperability
Software designed to support interoperable machine-to-machine interaction over a network
Glossary of Terms
Appendix 114
Term
WIMP
WS-BPEL
WSDL
WS-I BP
WWW
XML
XSD
Meaning
Window, Icon, Menu, Pointing device - see GUI
Web Services Business Process Execution Language - see BPEL
Web Services Description Language - an XML-based construct used to characterize web services T
Web Services Interoperability Basic Profile - a specification providing interoperability guidance for core
Web Services specifications such as SOAP, WSDL, and UDDI.
World Wide Web - a system of interlinked hypertext documents accessed via the Internet
eXtensible Markup Language - a set of rules for encoding documents in machine-readable form
XML Schema Definition - a set of rules to which a valid XML document must conform
Glossary of Terms
Appendix 115
NOTES
Glossary of Terms
Appendix 116
Appendix F. Bibliography
ARRA. (n.d.). American Recovery and Reinvestment Act of 2009. Retrieved March 2011, from Recovery.gov Track the Money: http://www.recovery.gov/About/Pages/The_Act.aspx
GWAC. (2008, March). Publications. Retrieved March 2011, from GridWise Architecture Council:
http://www.gridwiseac.org/about/publications.aspx
IEC. (2003). IEC 61968-1 - Application integration at electric utilities - System Interfaces for distribution
management - Part 1: Interface architecture and general requirements (Preview). Retrieved 2011, from
International Electrotechnical Commission Webstore: http://webstore.iec.ch/preview/info_iec619681%7Bed1.0%7Den.pdf
IEC. (2005). 61970-1 - Energy management system application program interface (EMS-API) - Part 1: Guidelines
and general requirements (Preview). Retrieved March 2011, from International Electrotechnical
Commission Webstore: http://webstore.iec.ch/preview/info_iec61970-1%7Bed1.0%7Db.pdf
IEEE. (n.d.). 2030 Smart Grid Interoperability Series of Standards. Retrieved March 2011, from IEEE Standards
Association: http://grouper.ieee.org/groups/scc21/dr_shared/2030/
NAE. (2011). Electrification. Retrieved March 2011, from Greatest Engineering Achievements of the 20th
Century: http://www.greatachievements.org/?id=2949
NETL. (2007, January). Smart Grid Implementation Strategy (SGIS) - Reference Shelf. Retrieved March 2011, from
NETL - the Energy lab - Where energy challenges converge and energy solutions emerge:
http://www.netl.doe.gov/smartgrid/refshelf.html#White%20Papers
NIST. (2010, January). NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0.
Retrieved March 2011, from National Institute of Standards and Technology:
http://www.nist.gov/public_affairs/releases/upload/smartgrid_interoperability_final.pdf
NIST. (2010, January). Smart Grid. Retrieved March 2011, from National Institute of Standards and Technology:
http://www.nist.gov/smartgrid/index.cfm
NIST-ITL. (2010, September). NIST - Computer Security Division - Computer Security Resource Center. Retrieved
March 2011, from National Institute of Standards and Technology:
http://csrc.nist.gov/publications/PubsNISTIRs.html
SGIP SGAC. (n.d.). SGAC Conceptual Architecture Working Party. Retrieved March 2011, from SGiP - NIST Smart
Grid Collaboration Site: http://collaborate.nist.gov/twikisggrid/bin/view/SmartGrid/SGIPConceptualArchitectureDevelopmentSGAC
SGMM. (n.d.). Smart Grid Maturity Model. Retrieved March 2011, from Software Engineering Institute |
Carnegie Mellon: http://www.sei.cmu.edu/smartgrid/
Bibliography
Appendix 117
SmartGridToday. (n.d.). Glossary of Terms and Abbreviations. Retrieved March 2011, from Smart Grid Today |
The Worldwide Daily Journal of the Modern Utility Industry:
http://www.smartgridtoday.com/public/department40.cfm
Southern California Edison. (2010). Smart Grid Strategy and Roadmap. Retrieved March 2011, from Southern
California Edison: http://asset.sce.com/Documents/Environment%20%20Smart%20Grid/100712_SCE_SmartGridStrategyandRoadmap.pdf
van Breeman, A. J. (2001). Agent-Based Multi-Controller Systems. Retrieved March 2011, from University of
Twente: http://www.ub.utwente.nl/webdocs/el/1/t000001c.pdf
White, A., Comport, J., & Schlier, F. W. (2005, January 17). Enterprise Information Management Is a Core
Element of Your IT Architecture.
Willis, R. (2006). Grid 2.0: The next generation. Retrieved March 2011, from Rebecca Willis:
http://www.rebeccawillis.co.uk/downloads/Grid20TheNextGeneration.pdf
Bibliography
Appendix 118

AMI Architecture Analys

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AMI Architecture Analys

Uploaded by

Copyright:

Available Formats

Smart Grid

Smart Grid Reference

About this document

Smart Grid Reference Architecture

Smart Grid Reference Architecture

The Smart Grid Architectural Challenge

Smart Grid Reference Architecture

Smart Grid Architecture

Smart Grid Architectural Goals and Principles

Smart Grid Architecture 3

Smart Grid Reference Architecture

Design for simplification by exploiting strategic assets

Smart Grid Architecture 4

Smart Grid Reference Architecture

Smart Grid Architecture 5

Smart Grid Reference Architecture

Smart Grid Architecture 6

Smart Grid Reference Architecture

From a Siloed Architecture to a Layered Services Architecture

Figure 4 - Silo Architecture for EMS/SCADA and Metering/Billing Functions

Smart Grid Architecture 7

Smart Grid Reference Architecture

Figure 5 - Enterprise Service Bus Architecture

Smart Grid Architecture 8

Smart Grid Reference Architecture

Figure 6 - Converged Communication Architecture

Smart Grid Architecture 9

Smart Grid Reference Architecture

Figure 7 System-of-Systems Architecture Based on Open Standard Services

Smart Grid Architecture 10

Smart Grid Reference Architecture

The system-of-system architecture shown in Figure 7 supports the following capabilities:

Smart Grid Architecture 11

Smart Grid Reference Architecture

Smart Grid Architecture 12

Smart Grid Reference Architecture

Smart Grid Domains and Cross Domain Foundational Services

Smart Grid Domains and Cross Domain Foundational Services 13

Smart Grid Reference Architecture

Smart Grid Reference Architecture Views

Figure 8 - Smart Grid Conceptual Model

Smart Grid Reference Architecture Views 14

Smart Grid Reference Architecture

Figure 9 - Layered Services Tier View

Each services group discussed in the following subsections provides a:

Smart Grid Reference Architecture Views 15

Smart Grid Reference Architecture

Applications Services Logical Model

Figure 10 - Application Services Logical Model

Smart Grid Reference Architecture Views 16

Smart Grid Reference Architecture

Smart Grid Reference Architecture Views 17

Smart Grid Reference Architecture

Application Services Structural Model

Smart Grid Reference Architecture Views 18

Smart Grid Reference Architecture

Figure 11 - Application Services Structural Model

Applications Architecture Specifications

Smart Grid Reference Architecture Views 19

Smart Grid Reference Architecture

Application access shall be tightly controlled.

The application shall use common auditing/logging

Applications must be protected from unauthorized access.

Smart Grid Reference Architecture Views 20