1. Session 4 – Release One Standards – Low Hanging Fruit
Objective:
Build towards consensus on the existing and emerging standards that have broad stakeholder acceptance
Indentify Standards Gaps
Process
Identify Principles for discussions
Map low hanging fruit to priority interfaces

2. Process
There is no defined governance so we will not petition any votes. We will bin standards into 3 categories. Those that do not fit in any of the categories will be left in an undefined bin.
Green: Are there any Candidate standards that have 100% agreement or very little opposing view– no brainers?
Yellow: Are there standards that are reasonably close, but may need caveats, additions, updates, constraints, or other qualifications? What are those qualifications?
Red: Are there standards that should not be in Release 1?
Ask for views on green first, then reds, then any yellows/discuss, finally if time left discuss undefined with the goal of moving to a color

3. ref: Utility Standards acceleration and lifecycle docs
Principles
Standards must:
Be Open
Facilitate 2-way secure communication
Follow the principle of segmentation of duties
Support Compliance
Provide mechanism for generational compliance
Follow a loosely coupled architecture
Is this list good, other?... discussion
ref: Utility Standards acceleration and lifecycle docs

4. Key Principles of Standards Strategy
Adoption
Open Governance
Participation
Acquisition
2. Separation of Duties
1. Openness
User Groups
SDOs
Industry Alliances
Certification
Process forces compliance with standards
3. Generational Compliance
4. Loose Coupling
1st
Generation
2nd
Generation
Certification
Certification
Process forces compliance with standards
Process forces compliance with standards

5. Initial Candidate List Low Hanging Fruit Standards mapped to session 3 list
ANSI C12.19 / IEEE 1377 / MC1219
IEEE C37.118
IEC 61968/61970 (CIM)
MultiSpeak
IEEE 1547
BACnet – ASHRAE/ANSI 135, ISO
IEC 61850
IEC TASE.2
DNP3
IEC 62351
NERC CIP
NIST Security Standards – FIPS 140-1, NIST SP800-53, NIST SP800-82, etc.
IEEE 802 family
IETF Internet Standards – TCP/IP, VPNs, TLS, SNMP, etc.
IEC PAS 62559
HomePlug/ZigBee Alliance Smart Energy Profile
UtilityAMI 2008 HAN Systems Requirements Specification
UtilityAMI UtiliSec/AMI-SEC Specification 5

6. ANSI C12.19 / IEEE 1377 / MC1219
Application: End devices, including revenue metering applications, information model
Actors: End Device (including Meters), Head End, Collector, Handheld Interrogator
Interfaces: Multiple media – optical, wired, and wireless
Maturity: Ultra wide acceptance, has governance, has certification and testing,
Category: SDO – ANSI / IEEE 1377/ MC1219 – American National Standard, IEEE Standard, Measurement Canada Standard
Issues: Used primarily in North America, competes with other standards internationally, aging from an IT technological sophistication perspective.

7. IEC 61968/61970 Common Information Model (CIM)
Application: Enterprise information representation, including transmission, distribution, back office metering
Actors: Databases, software applications
Interfaces: Ethernet and IP based communications, XML/SOAP
Maturity: Wide acceptance in concept, has governance, has users group, however, no certification, interoperability has not been standardized, and significant testing is required
Category: SDO - International (IEC) Standard
Issues: Needs application specific extensions to extract maximum value, competes with NRECA MultiSpeak although harmonization effort is in progress.

8. IEEE 1547 for DER
Application: Physical and Electrical Interconnections
Actors: Customers, vendors, utilities
Interfaces: Point of Common Coupling (PCC)
Maturity: Wide acceptance and implementation by utilities, vendors, and their customers
Category: SDO - IEEE
Issues: On-going work to address networked power systems, testing, and other issues

9. BACnet – ASHRAE/ANSI 135, ISO 16484-5
Application: building automation
Actors: Building EMS, building infrastructure devices
Interfaces: Serial, Ethernet, IP – wired and wireless
Maturity: Widely accepted nationally, has governance, has users group, has certification and testing
Category: SDO – National (ASHRAE/ANSI) and International Standard (ISO)
Issues: Supports IP through BACNet/IP in Annex J

10. IEC 61850
Application: Substation Automation and Protection, Distribution Automation, Distributed Energy Resources, Hydro Generation, SCADA to field devices
Actors: Protective relays, SCADA Master, DER, PQ Meters, fault recorders, applications
Interfaces: Ethernet and IP based communications, with on-going work for network architecture to address environments with different network constraints
Maturity: Wide acceptance, into third round of update, has governance, has users group, has certification and testing
Category: SDO - International Standard
Issues: competes/overlaps with DNP3 in some applications, best practice for high speed relay-to-relay communication, wide acceptance internationally, growing acceptance nationally for green field application

11. DNP3 Application: Substation and feeder device automation
Actors: Protective relays, metering devices, cap bank controllers, switches, SCADA Master, applications
Interfaces: Serial, Ethernet, IP over TCP or UDP,
Maturity: Ultra wide acceptance nationally, has security built in, has governance, has users group, has certification and testing
Category: De facto, Open, Industry Standard
Issues: competes/overlaps with IEC in some applications, aging somewhat from an IT technological sophistication point of view, register based, no inherent semantic meaning to registers

12. IEEE 802 family of Standards
Application: Wireless standards and wireless security
Actors: Many
Interfaces: Many
Maturity: Depends on subpart (Ethernet) is ultra mature (WiFi) and (Bluetooth and Zigbee) are very mature (WiMax) is widely accepted but early in its life and adoption cycle i (wireless security) is widely accepted and implemented
Category: SDO – IEEE
Issues: Fundamental communications standard. Selection of specific subpart to implement depends on application requirements.

13. IETF Internet Standards – TCP/IP, VPNs, TLS, SNMP, etc.
Application: Where appropriate for public and private internets and communications
Actors: Many
Interfaces: Many
Maturity: Very mature in most cases
Category: SDO – IETF
Issues: Not appropriate for all Smart Grid environments. Selection of specific standards highly dependent on application requirements – especially non-functional requirements related to bandwidth, latency, and reliability

14. HomePlug/ZigBee Alliance Smart Energy Profile
Application: Home Area Network (HAN) Device Communications and Information Model
Actors: Meter / HAN Gateway, HAN Device
Interfaces: Multiple media – wireless and Power Line Carrier (PLC)
Maturity: Initial release, has governance, has users group, has certification and testing
Category: De facto, Open, Industry Consortia Specification
Issues: Need to complete separation of information model from technology specifics

15. UtilityAMI 2008 HAN Systems Requirements Specification
Application: Home Area Network device communication, measurement, and control
Actors: Energy Service Interface, HAN Devices
Interfaces: Technology and GridWise Architecture Council (GWAC) layers 1-3 independent
Maturity: First version, wide acceptance, has governance, no certification or testing
Category: De facto, Open, Industry Consortia Requirements Specification,
Issues: Planned for publication as an IEC Publicly Available Specification

17. Definitions of Open Standards
References
[1] Microsoft Definition:  'standard' means a technology approved by formalized committees that are open to participation by all interested parties and operate on a consensus basis. An open standard is publicly available, and developed, approved and maintained via a collaborative and consensus driven process
[2] One of the most popular definitions of the term "open standard", as measured by Google ranking, is the one developed by Bruce Perens. [3] His definition lists a set of principles that he believes must be met by an open standard:
Availability: Open Standards are available for all to read and implement.
Maximize End-User Choice: Open Standards create a fair, competitive market for implementations of the standard. They do not lock the customer in to a particular vendor or group.
No Royalty: Open Standards are free for all to implement, with no royalty or fee. Certification of compliance by the standards organization may involve a fee.
No Discrimination: Open Standards and the organizations that administer them do not favor one implementor over another for any reason other than the technical standards compliance of a vendor’s implementation. Certification organizations must provide a path for low and zero-cost implementations to be validated, but may also provide enhanced certification services.
Extension or Subset: Implementations of Open Standards may be extended, or offered in subset form. However, certification organizations may decline to certify subset implementations, and may place requirements upon extensions (see Predatory Practices).
Predatory Practices: Open Standards may employ license terms that protect against subversion of the standard by embrace-and-extend tactics. The licenses attached to the standard may require the publication of reference information for extensions, and a license for all others to create, distribute, and sell software that is compatible with the extensions. An Open Standard may not otherwise prohibit extensions.
[3]  Bruce Perens,