1
SG-Systems (Smart Grid Operational
Applications Integration) Charter Status
Greg Robinson, Co-Chair, SG-Systems
Brent Hodges, Chair, SG-Systems
2
OpenSG Subcommittee Organization
3
NIST Conceptual Model
Source NIST Interim Roadmap
4
Source NIST Interim Roadmap
5
Business Drivers

• Interoperability requires many standards in a
  profile stack
• Work with relevant SDOs per layer of profile
  stack (e.g., information standards, security
  standards, transport standards, media standards,
  etc.) to ensure complete solutions for in-scope
  interfaces.
• Need formal industry standards, but the SDO
  process is relatively slow needs more user
  input
• Work collaboratively with SDOs to ensure common
  user requirements are appropriately 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.
• To ensure consistency of information across all
  domains, SG-Systems WG is assigned the task of
  defining requirements and proposing solutions to
  gaps in existing standards.

6
SG-Systems WG Scope

• SG-Systems WG
• 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, etc.).
• Task forces are established on an as needed basis
  to accomplish these goals for specific functional
  areas. In addition to work performed by their
  vertical team, Task Force Chairs act as matrix
  managers to ensure their functional requirements
  are met through the horizontal teams supporting
  them.
• Horizontal Teams are ongoing, providing
  consistent artifacts for each increment of
  functionality that is requested of them by the
  functional (vertical) teams.

7
SG-Systems WG Process Overview- A Well Oiled
Machine
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
Use Case Team
System Requirements (SRS) Team
Service Definitions Team

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

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

Interoperability Testing Team
8
SG-Systems Organization Structure
Underway With NAESB
Underway
Underway With NAESB
Underway
Collaboration With SE 2.0 OASIS
Collaboration With SE 2.0
Planning
Collaboration With SE 2.0 OASIS
Collaboration With SE 2.0
Planning
Planning
Collaboration With SE 2.0 OASIS
Collaboration With SE 2.0
Underway
Underway
9
Key Collaboration Concept for the SG-Systems
Working Group

• Standard building blocks are defined by CIMug and
  the affiliated IEC working groups along with
  other relevant industry groups
• e.g., 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 standard building
  blocks.
• Recommended extensions and changes to standard
  building blocks are provided back to appropriate
  standards bodies.

10
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

11

• The scope of AMI-ENT is the systems and/or
  applications within and around the utility
  enterprise and the inter-systems related business
  functions and stops at the boundaries of
  applications and the edge of utility enterprise.
• The focus is on how these systems are to be
  integrated and composed to support AMI related
  business processes and functions.
• Edge applications are those applications that
  communicate with networks and devices in the
  field, as well as those that communicate with
  other businesses or enterprises (generally
  defined as third parties).

12
An Open AMI from AMI-Ents SRS
13
AMI-Ent Reference Model
14
Use Case Driven
15
CIM-Based Service Identification
16
Inventory of 142 CIM-Based Services Supporting
Use Cases for AMI-Enterprise (Refer to
http//www.smartgridipedia.org/index.php/AMI_Enter
prise)
17
OpenHAN - Home Area Network
18
OpenHAN

• OpenHAN SRS 1.04 ratified March 2008
• SRS used by ZigBee and HomePlug technology
  alliances as basis for SE 2.0 Market Requirements
  Document (MRD)
• OpenHAN to update SRS based on SE 2.0 MRD and
  market developments
• OpenHAN to review SE 2.0 artifacts as provided to
  facilitate NIST open review process
• Technical Requirements Document
• Proposed CIM Extensions
• Proposed Service Definitions

19
OpenADE - Automated Data Exchange
20
OpenADE

• Permits utilities to share, at the consumers
  request and under the consumers direction, a
  broad set of that consumers utility data with
  specific 3rd Parties.
• Immediate Scope (i.e. OpenADE 1.0) includes usage
  data from utility back end
• Broader Vision (requirements due post-01/2009)
  includes pricing, network events, premises
  configuration, HAN-related data, etc.

21
OpenADE Timeline / Status

• 04/09 Automated Data Exchange group commissioned
  at OpenSG quarterly meeting
• 05/09 Begin weekly meetings to gather business
  requirements / use cases / user requirements
• 08/09 Initiate SRS, Services work (in parallel
  w/ requirements gathering)
• 10/09 Ratify initial Requirements collection
  (v1.0)
• 12/09 Preliminary SRS, Services definitions
  (v0.1)
• 01/10 Ratify initial SRS, Services definitions
  (v1.0)
• 01/10 Follow on Requirements collection, to
  include additional elements identified at NIST
  Smart Grid Workshop

22
OpenADE Participants
Utilities 3rd Parties Consumer
Consumers Energy Tendril Networks Citizens Utility Board
Florida Power and Light Google UCAN
Oncor Greenbox
Pacific Gas and Electric Comverge
Reliant Juice Technologies
Southern California Edison
San Diego Gas Electric
Xtensible Solutions (consultants)
23
OpenADR Automated Demand Response
24
OpenADR

• Focused on requirements and specifically on
  deliverables for NIST PAP 09.
• Currently engaged with horizontal Use Case and
  SRS teams within UCA.
• In discussions with NAESB and OpenHAN on
  collaboration on NIST PAP 09 deliverables.
• Next steps
• Analyze existing work product from Use Case and
  SRS teams to recommend changes and extensions.
• Become more closely engaged with NAESB on
  collaboration and participate in joint taskforce.

25
Remarks on Working Closely With SDO

• In recent NIST discussions, there is general
  agreement that formal standards are needed.
• While IEC is viewed as necessary, it suffers from
  two major criticisms
• The IEC process is too slow
• There is not enough user participation in IEC
  standards development
• IEC TC57 helped form the UCAIug. OpenSG is a
  user-driven organization that functions as part
  of the UCAIug
• OpenSG is able to work with the IEC to resolve
  these two criticisms
• OpenSG ballots its work products and make them
  publically available as an Industry Best
  Practice
• Please note that these are NOT standards as
  OpenSG is not a standards development
  organization (SDO).   
• OpenSG work products are intended to become a
  common best practice based on applicable industry
  standards.  
• Extensions to standards that were needed to meet
  OpenSGs business requirements will be provided
  to the appropriate SDO (e.g., IEC TC57 WG14).  
• The OpenSG hopes that the SDOs will accept its
  recommended extensions (and the extension will
  become part of the next release of the
  standard(s)
• In the meantime, the user community has something
  to leverage that is far better than custom
  extensions performed differently at each
  individual utility.