SG-Systems Working Group

1
SG-Systems Working Group

• Status
• Active, meet once at each face-to-face meeting
• 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.

2
(No Transcript)
3
OpenHAN

• Status
• Hibernating
• Charter
• Updates System Requirements Specification (SRS)
  to Version 2.0
• 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
• Deliverables
• SRS 2.0 (completed)

3
4
OpenHAN History
4
5
Service Definitions Team

• Status
• Hibernating
• Charter
• Assist SG-Systems Task Forces with the following
  process
• Business process analysis
• Integration requirements detailed in sequence
  diagrams
• Service and operation pattern applied
• Service and information object identification and
  harmonization
• Data modeling and artifacts generation
• Artifacts validation and testing
• Artifacts version control and issue tracking
• Deliverables
• Provided through task forces on an as needed basis

6
OpenADR

• Status
• Hibernating
• Charter
• The UCAIug OpenADR TF focuses on developing best
  practices, use cases and business requirements
  for DR from an application point of view and
  specifically on the interactions between the
  Utility and Facility.
• Deliverables
• Task Force completed 1.0 SRS and SD in 2010
• Phase 2 SRS (Addressed additional requirements
  for PEV, DER, FastDR, Security) completed and
  ratified Jan. 2012
• Develop and contributed Security profile to
  OpenADR Alliance in 2010

7
AMI-Enterprise TF

• Status
• Superceded by SG Enterprise (see subsequent
  slides)
• Charter
• Defines requirements, policies, and services to
  support AMI related business processes and
  functions.
• Based on utility industry standards such as the
  Common Information Model (CIM) and best
  practices.
• Required for information exchange and control
  between the MDMS or MDUS and enterprise back
  office systems.
• Deliverables (all completed)
• System Requirements Specification (SRS)
• Use Cases
• Service Definitions

AMI-Ent TF
Slide 7
8
SG Enterprise

• Status
• New - Face-to-face meetings and weekly conference
  calls
• Charter
• The scope of SG-ENTERPRISE 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. 
• SG-ENTERPRISE 2.0 charter will leverage available
  and applicable industry best practices and
  standards for this work, and to tie the required
  pieces together to support the implementation of
  AMI related processes, applications, and
  infrastructure technologies.  SG-Enterprise 2.0
  will provide specific requirements and supporting
  artifacts that support the implementation of AMI
  profile (i.e. strongly typed profiles).

9
SG Enterprise - continued

• Deliverables
• Updated System Requirements Specification (SRS)
• Based on existing AMI-Enterprise SRS
• Corrected versions of existing AMI-Enterprise use
  cases based on feedback from SDOs
• Development of new use cases and artifacts where
  gaps exist

10
OpenADE

• Status
• Active Face-to-face meetings and weekly
  conference calls.
• Charter
• UCAIug OpenSG OpenADE shall promote
  interoperability for Green Button
• Based on NAESB REQ.21 Energy Services Provider
  Interface (ESPI).
• Collect and refine changes and extensions to ESPI
  and related standards.
• Develop and manage Green Button conformance
  profiles including
• Green Button Download My Data
• Green Button Connect My Data
• Additional profiles as needed
• Develop and manage technical artifacts of a Green
  Button certification program.
• Develop and manage test plans and conformance
  profiles.
• Ensure availability of testing software.
• Coordinate with and participate in UCAIug ITCA
  development.
• Collaborate with OpenESPI and other related
  efforts.
• Support UCAIug marketing group(s) in promoting
  the standard.

11
OpenADE - continued

• Deliverables
• All milestones targeted for November 2012 OpenSG
  meeting
• Full ESPI test plan complete
• ITCA operational
• Ability to certify ready
• OpenADE / ESPI 1.1 requirements approved to
  submit to NAESB
• ESPI 1.1 complete? 

12
Enterprise Information Management (EIM)

• Status
• Active Face-to-face meetings and biweekly
  conference calls.
• 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 12
13
Enterprise Information Management (EIM) -
continued

• Deliverables
• EIM Requirements Specification
• Use Cases
• Guidelines and recommendations for utilities to
  incorporate EIM into their existing SDLC
  processes
• Enterprise Semantic Model Requirements and
  Guidelines

Slide 13
14
OpenMUG

• Status
• New
• Charter
• The purpose of the Open Meter Users Group
  (OpenMUG) is to provide a forum in which utility
  operators, meter manufacturers and interested
  third-party integrators can meet to discuss
  meter-related issues that could reasonably be
  solved by the group. Some hypothetical examples
  of such issue/solution pairs might be
• Differing interpretations of a communication
  standard/recommendation to the standards
  organization
• Uncertainty about how to manage meter
  passwords/whitepaper describing recommended
  practice
• Desire for common electronic format of meter test
  data/proposal to standards organization
• To guide the groups work, the first item to be
  produced is a document enumerating issues to be
  considered. After the issues are listed,
  subsequent meetings will evaluate possible
  solutions and prioritization. If the group finds
  itself with no further items, it is expected that
  it would either recharter or disband.
• The Open Meter Users Group shall follow the
  UCAIug guiding principles.

15
OpenMUG - continued

• Charter Scope
• The activities of the Open Meter Users Group
  shall be limited in scope in order to support
  proper division of labor with respect to the
  other UCA groups. The focus will be on meter
  communications issues and system issues with
  regard to meters. It will not treat the topic of
  security or testing except as it relates directly
  to either meter communications or metering system
  issues. Head-end integration with other business
  applications is specifically out of scope.
• Deliverables
• Document enumerating issues to be considered
• Others TBD

16
GIS

• Status
• The task force has had one organizing meeting (at
  Cincinnati) and will meet at New Orleans to begin
  the process of defining requirements.  Regularly
  scheduled teleconferences (probably biweekly) are
  expected to begin after the New Orleans meeting.
• Charter
• The OpenSpatial task force was established to
  define requirements for a harmonization between
  geospatial information standards maintained by
  the Open Geospatial Consortium and
  asset-management and electric network
  connectivity modelling standards maintained by
  Technical Committee 57 of the International
  Electrotechnical Commission. The goal is to
  enable the two sets of standards to incorporate
  each others material by reference and without
  bringing their respective governance practices
  into conflict.
• Deliverables
• Requirements specification