1. “SG-Systems” (Smart Grid – Operational Applications Integration) Charter & Status
Brent Hodges,
Chair, SG-Systems
Greg Robinson,
Co-Chair, SG-Systems

2. OpenSG Subcommittee Organization

3. NIST Conceptual Model Focus Of SG-Systems
[Source: NIST Interim Roadmap]

4. 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 (don’t 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.

5. 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.

6. SG-Systems WG Process Overview - “A Well Oiled Machine”
NIST
EPRI,
MultiSpeak
HomePlug
& ZigBee
SE 2.0
IEC TC57 WG14,
OASIS, IEEE
Other SDOs
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

7. 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

8. 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.

9. Utility’s
Projects
- Design &
Implementations
Architecture
Industry Best Practices
Interoperability Testing
Standards Conformance &
Industry Standards
Our Focus: Finding/Developing Best Practices & Making Them into Vetted “Industry Best Practices”
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 series of standards

10. 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).

11. An Open AMI from AMI-Ent’s SRS

12. AMI-Ent Reference Model

13. Use Case Driven

14. CIM-Based Service Identification

15. Inventory of 142 CIM-Based Services Supporting Use Cases for AMI-Enterprise (Refer to

16. OpenHAN - Home Area Network

17. 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

18. OpenADE - Automated Data Exchange

19. OpenADE
Permits utilities to share, at the consumer’s request and under the consumer’s direction, a broad set of that consumer’s 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.

20. 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

21. 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)

22. OpenADR – Automated Demand Response

23. 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.

24. 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 OpenSG’s 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.