1
SG-Systems (Smart Grid Operational
Applications Integration) Boot Camp Overview
Greg Robinson, Co-Chair, SG-Systems
Brent Hodges, Chair, SG-Systems
2
Agenda

• Introductions and Brief Overview of SG-Systems
• Requirements Gathering Use Cases and System
  Requirements Overview with AMI-Ent example
• OpenADE
• OpenADR
• OpenHAN
• EIM Task Force
• General discussion, questions answers
• Adjourn

3
(No Transcript)
4
NIST Conceptual Model
Source NIST Interim Roadmap
5
Source NIST Interim Roadmap
6
Business Drivers

• Interoperability requires many standards in a
  profile stack
• The SDO process is relatively slow needs more
  user input
• Work collaboratively with SDOs to ensure common
  user requirements are addressed
• Facilitate standards development by proposing
  potential solutions for addressing gaps in
  existing standards.
• The SDO ultimately determines when and how its
  standards are updated based on input.
• For Information Standards, resolve (dont add to)
  semantic chaos
• Avoid having the same information defined with
  different names, varying definitions, etc.
• Ensure same information standards can be used
  across different communication profiles
• While mapping to other standards will be
  unavoidable, strive to use, correct and extend
  one information model standard
• The IEC TC57 Common Information Model (CIM) is
  the default information model for this purpose.
• There is substantial information overlap among
  AMI, ADE, HAN and ADR
• While requirements and services vary
  significantly, they can be built using the same
  information model.

7
The CIM is the Basis for a Common Systems
Language for Utilities

• The same dictionary is used for multiple forms of
  human communication
• Letters
• Phone calls
• Conversations
• Emails
• Etc.
• In similar manner, the same CIM is used for
  multiple forms of computer communication
• XML
• RDF
• OWL
• DDL
• Etc.

7
Proprietary and Confidential
8
SG-Systems Working Group

• Charter
• The SG-Systems Working Group defines
  requirements, policies, and services, based on
  utility industry standards such as the Common
  Information Model (CIM), required for information
  exchange from and to utility enterprise back
  office systems and between these back office
  systems and data acquisition and control servers
  (e.g., MDMS, AMI Head Ends, SCADA, OMS, GIS, CIS,
  work management, etc.).
• Task forces are established on an as needed basis
  to accomplish these goals for specific functional
  areas.

9
SG-Systems WG Process Overview
NIST
EPRI, MultiSpeak
IEC TC57 WG14, OASIS, IEEE Other SDOs
HomePlug ZigBee SE 2.0
Use Cases From SCE and others
Task Forces
Business-Oriented, Common Format Use Cases Based
on SRS Reference Model
System Requirements Specification (SRS)
Use Case Development
SG-Security WG
Service Definitions (supporting SDOs)

• Integration Requirements
• Patterns
• Sequence Diagram
• Services
• WSDL

• Recommendations to IEC TC57 WG14
• Proposed CIM Extensions
• Message Schemas Updates
• Requirements Updates
• Recommendations to other SDOs

SG-Conformity WG
10
Key Collaboration Concept for the SG-Systems
Working Group

• Standard building blocks are defined by IEC,
  other Standards Development Organizations, and
  industry groups
• e.g., OAISIS, Open Applications Group (OAG),
  MultiSpeak, OGC
• Requirements (use cases) are gathered from
  helpful sources
• Utilities
• Industry initiatives
• The SG-Systems WG articulates Industry Best
  Practices (see next slide) that satisfy
  requirements through the use of industry standard
  building blocks.
• Ideas for recommended extensions and changes to
  standard building blocks are provided back to
  appropriate standards bodies.

SG-Systems WG
February 2010
11
Our Focus Finding/Developing Best Practices
Making Them into Vetted Industry Best Practices
Utilitys Projects - Design Implementations ---
------------ Utilitys Architecture -------------
---------- Industry Best Practices Interoperabilit
y Testing --------------------------------- Indust
ry Best Practices --------------------------------
---------- Standards Conformance
Interoperability Testing ------------------------
----------------------------- Industry
Standards

• Local Utility Projects
• Consortiums User Groups like OpenSG (business
  requirements) CIMug (optimization
  implementation support)
• Standards Development Organizations (SDOs) like
  IEC TC57 Working Group 14 for the IEC 61968
  series of standards

SG-Systems WG
12
Agenda

• Introductions and Brief Overview of SG-Systems
• Requirements Gathering Use Cases and System
  Requirements Overview with AMI-Ent example
• OpenADE
• OpenADR
• OpenHAN
• EIM Task Force
• General discussion, questions answers
• Adjourn

13
Agenda

• Introductions and Brief Overview of SG-Systems
• Requirements Gathering Use Cases and System
  Requirements Overview with AMI-Ent example
• OpenADE
• OpenADR
• OpenHAN
• EIM Task Force
• General discussion, questions answers
• Adjourn

14
Agenda

• Introductions and Brief Overview of SG-Systems
• Requirements Gathering Use Cases and System
  Requirements Overview with AMI-Ent example
• OpenADE
• OpenADR
• OpenHAN
• EIM Task Force
• General discussion, questions answers
• Adjourn

15
Scope of HAN SRS in the NIST conceptual model
15
16
OpenHAN - Scope
16
17
OpenHAN History
17
18
OpenHAN 2.0 Effort

• Over 130 individuals representing over 80
  companies participated in the development of the
  HAN SRS v 2.0 over a 10 month period

19
Documents Reviewed

• Industry use cases were reviewed to identify any
  gaps
• ZigBeeHomePlug SEP MRD
• SAE J2836/1 J2836/2 and J2836/3 Use Cases
• NAESB Draft Requirements Specifications for NIST
  PAP03, PAP04, and PAP09
• EIS Alliance Customer Domain Use Cases v1.0
• CEC Requirements Engineering for the Advance
  Metering Infrastructure and the Home Automation
  Network (AMI-HAN) interface February 2008
• AHAM Smart Grid White Paper
• DER Contribution to OpenHAN EPRI/DOE PV/Storage
  Communication Project
• Summary of Use Cases For Demand Response
  Appliances Interface (EPRI Adapters)
• February 2010 NISTIR 7628 Smart Grid Cyber
  Security Strategy and Requirements

20
UCAIug HAN SRS v2.0

• Purpose
• Define the system requirements for an open
  standard Home Area Network system
• Promote open standards-based HANs that are
  interoperable
• Provide the vendor community with a common set of
  principles and requirements around which to build
  products
• Ensure reliable and sustainable HAN platforms
• Support various energy policies in a variety of
  states, provinces, and countries
• Empower consumers to manage their electricity
  consumption by giving them the information and
  control they need to make decisions on their
  energy use

20
21
UCAIug HAN SRS v2.0

• Architectural Considerations
• HAN SRS applies from the edge of the AMI System,
  where the Energy Services Interface (ESI)
  resides, to all relevant HAN Devices in the
  premises
• Energy Services Interface (ESI)
• An interface which enables communication between
  authorized parties and HAN devices that are
  registered to it
• There may be more than one ESI in the premise
  (e.g. Utility ESI, 3rd party ESI)
• Utility ESI provides interface between the
  Utility AMI network and HAN devices, including
  the AMI meter
• Other ESI provides interface between other
  communication media (e.g. internet, cell phone,
  EMS, etc.) and HAN devices registered to it

21
22
UCAIug HAN SRS v2.0

• Architectural Considerations, continued
• Commissioning, Registration, Enrollment
• Commissioning is the process by which a HAN
  device obtains access to a specific physical
  network and allows the device to be discovered on
  that network
• Registration is the process by which a
  Commissioned HAN device is authorized to
  communicate on a logical network by exchanging
  security credentials with an ESI
• Enrollment is the process by which a Consumer
  enrolls a Registered HAN device in a Service
  Provider program (e.g. demand response, energy
  management, PEV program, etc.)

22
23
This figure shows the type of communication a HAN
Device may engage in, which is dependent upon its
relationship with the ESI and the Service
Provider.
23
24
UCAIug HAN SRS v2.0

• Architectural Considerations, continued
• HAN SRS is agnostic to device ownership
• Some HAN devices may reside on more than one ESI
• HAN SRS is agnostic to electric market structure
  and is applicable to both integrated utility
  markets as well as consumer choice electric
  markets
• There may be multiple communication paths into
  the HAN (e.g. Utility AMI, internet, cell phone
  network, EMS, etc.)
• HAN SRS addresses the following special
  applications
• Plug-in-Electric Vehicle (PEV)
• Energy Management System (EMS)
• Distributed Energy Resources (DER)

24
25
UCAIug HAN SRS v2.0

• HAN System Requirements
• Application Requirements
• Control applications respond to control signals
• Measurement and Monitor applications provide
  internal data and status
• Processing applications consume, process, and act
  on external and internal data
• Human Machine Interface (HMI) provides Consumers
  a means to provide input into an application or
  to view information from an application
• Communication Requirements
• Commissioning is the network process of adding a
  HAN device on the HAN to allow the device to
  communicate with other devices and involves
  network scanning, selection, admission, and
  configuration
• Control of a node involving self-organization,
  path selection, mitigation

25
26
UCAIug HAN SRS v2.0

• HAN System Requirements, continued
• Security Requirements
• Access Controls and Confidentiality address data
  protection for data-at-rest and data-in-transit
• Registration is the network process to
  authenticate and authorize HAN device
  participation with an ESI and includes
  initialization, authentication, correlation,
  authorization, and de-register
• Enrollment is the process by which a Consumer
  enrolls a HAN device in a Service Providers
  program (e.g. demand response, energy management,
  pre-pay, PEV programs, distributed generation,
  pricing, messaging, etc.) and gives certain
  rights to the Service Provider to communicate
  with their HAN device
• Integrity preserves the HAN operating environment
  through resistance and recovery
• Accountability will allow for monitoring
  malicious activities through audit and
  non-repudiation

26
27
UCAIug HAN SRS v2.0

• HAN System Requirements, continued
• Performance Requirements
• Ensure applications or other factors do not limit
  the performance of the system, which is dependent
  upon availability, reliability, maintainability,
  scalability, upgradeability, quality and latency
• Operations, Maintenance, and Logistics
  Requirements
• Manufacturing and Distribution - Vendors
  pre-installation activities including
  pre-Commissioning settings, application
  configuration, labeling, support for multiple
  distribution channels
• Installation Documentation for the physical
  placement of the device and support systems
• Manage, Maintain ensure HAN device diagnostic,
  management and trouble shooting capabilities
  including alarming, logging, testing, device
  reset, and monitoring

27
28
Questions????

• UCAIug HAN SRS v2.0 is located on the OpenHAN
  sharepoint
• http//osgug.ucaiug.org/sgsystems/openhan/default.
  aspx

28
29
Agenda

• Introductions and Brief Overview of SG-Systems
  (Greg)
• Requirements Gathering Use Cases and System
  Requirements Overview with AMI-Ent example (Mark)
• OpenADE (Steve or Dave)
• OpenADR (Bruce)
• OpenHAN (Erich)
• EIM Task Force (Jim)
• General discussion, questions answers
• Adjourn

30
Smart Grid Interoperability

• Ability of systems to operate in coordination
• Ability to exchange and use information
  appropriately
• Requires standard interface definitions
• Governed by open industry working groups
• Provides Benefits
• Promotes loosely-coupled integration
• Allows incremental functional enhancements
• Creates market for reusable, compatible
  components
• Only one integration instead of many
• To an open, public, standard interface
• Instead of each proprietary vendor or utility
  interface

31
Smart Grid Challenges

• Requires Integration LOTS of integration
• Onslaught of new applications and technologies
• AMI, MDMS, HAN, DR, ADE, etc.
• In a complex IT environment
• Many custom systems, legacy technologies
• Typically departmentally controlled within
  silos
• Need ability to govern, manage, and share
  resources
• at the Enterprise level and beyond (external
  services)
• Aging / outsourced systems and IT workforce
• Historically, extremely low RD expenditures
• Must ramp up capabilities quickly
• Each utility has its own Software Development
  Life Cycle (SDLC)

32
Its More Than Just Technical Matters
Driving Forces
Restraining Forces

1. Lack of stable industry standard definitions
2. Vendors way lower project costs
3. Vendors pushing for proprietary lock-in
4. Consultants pushing to be thought leaders
5. Hours-sold revenue driving System Integrators
6. Internal system experts want to remain experts
7. Project managers striving for control
8. Inertia why change?
9. Our situations unique standards hinder us

1. Consistent enterprise-wide data
2. One version of the truth
3. Access to data regardless of source
4. Business transformation agility
5. Reduced project implementation costs
6. Reduced maintenance costs
7. Reduced IT risks
8. Availability of external services
9. Scalable business process automation
10. Scalable business activity monitoring
11. Accurate reporting regulatory, KPIs
12. Mergers and acquisitions

Status Quo
For further information, please refer to the
article on page 56 of the January issue of
Utility TD Automation Engineering
http//www.uae-digital.com/uae/200801/
33
Defining EIM (Gartner)

• Enterprise Information Management (EIM) is
• An organizational commitment to structure, secure
  and improve the accuracy and integrity of
  information assets,
• to solve semantic inconsistencies across all
  boundaries,
• and support the technical, operational and
  business objectives within the organization's
  enterprise architecture strategy.
• A commitment to EIM is recognition that
  information in the enterprise is as important as
  process (application development) and
  infrastructure (technology)

34
Overall EIM Framework
35
EIM Charter

• Identify and articulate common EIM requirements
• Use cases
• Activity Diagrams
• EIM Requirements Specification
• Develop common EIM Framework that satisfies
  requirements, taking advantage of other relevant
  industry work as appropriate (e.g., vision,
  governance, processes, etc.)
• Develop requirements for an OpenSG generic
  semantic model to be used by members as a
  starting point for their enterprises.
• Collaborate with SGAC of the NIST SGIP
• Provide a forum for exchanging information so
  that all members can benefit from lessons
  learned.
• Collaborate with Standards Development
  Organizations (SDOs), NIST SGIP, and/or
  consortiums so that needed advancements are
  accomplished in the most appropriate
  organizations in the most efficient manner.

Slide 35
36
Agenda

• Introductions and Brief Overview of SG-Systems
  (Greg)
• Requirements Gathering Use Cases and System
  Requirements Overview with AMI-Ent example (Mark)
• OpenADE (Steve or Dave)
• OpenADR (Bruce)
• OpenHAN (Erich)
• EIM Task Force (Jim)
• General discussion, questions answers
• Adjourn