1 / 69

PAPs 3,4,9,10 Session

PAPs 3,4,9,10 Session. David Holmberg, David Wollman Wednesday May 26, 2010. Agenda. Context for consumer interface PAPs PAPs 3, 4, 9 perspective How we move forward in the PAPs—where we are in the PAP process. Review of draft specifications: Smart Energy 2.0 (SEP2)

aisha
Télécharger la présentation

PAPs 3,4,9,10 Session

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PAPs 3,4,9,10 Session David Holmberg, David Wollman Wednesday May 26, 2010

  2. Agenda • Context for consumer interface PAPs • PAPs 3, 4, 9 perspective • How we move forward in the PAPs—where we are in the PAP process. • Review of draft specifications: • Smart Energy 2.0 (SEP2) • Energy Interoperation (EI) • Energy Market Info eXchange (EMIX) • WS-Calendar • A presentation on Transactional Energy • Open discussion

  3. Some context for the consumer interface PAPs: • EISA serves as a foundation and guidance for the NIST effort. • The legislation gave us priority issues for smart grid that have not changed. • The NIST process (2008-2009) led to selection of key standards interoperability issues (PAPs) that line up well with EISA. • We continue the job of fulfilling national need to address these key standards.

  4. EISA 2007 TITLE XIII--SMART GRID SEC. 1301. STATEMENT OF POLICY ON MODERNIZATION OF ELECTRICITY GRID. It is the policy of the United States to support the … Smart Grid: (1) Increased use of digital information and controls technology to improve reliability, security, and efficiency of the electric grid. (both grid side and facility side) (2) Dynamic optimization of grid operations and resources, with full cyber-security. (3) Deployment and integration of distributed resources and generation, including renewable resources. (PAP9) (4) Development and incorporation of demand response, demand-side resources, and energy-efficiency resources. (PAP9) (5) Deployment of `smart' technologies (real-time, automated, interactive technologies that optimize the physical operation of appliances and consumer devices) for metering, communications concerning grid operations and status, and distribution automation. (6) Integration of `smart' appliances and consumer devices. (PAP9, 10) (7) Deployment and integration of advanced electricity storage and peak-shaving technologies, including plug-in electric and hybrid electric vehicles, and thermal-storage air conditioning. (PAP9) (8) Provision to consumers of timely information and control options. (PAP10) (9) Development of standards for communication and interoperability of appliances and equipment connected to the electric grid, including the infrastructure serving the grid. (PAP3,4,9,10) (10) Identification and lowering of unreasonable or unnecessary barriers to adoption of smart grid technologies, practices, and services.`

  5. PAP 9 DR and DER • “collaborative energy” and “managed energy” • all energy is managed • Gist of “collaborative energy” is peer interaction across a shallow interface. • Residential vs. Commercial and Industrial (C&I) • Different markets, different controls environments • Requires different DR approaches. • PAP 9 has 2 track approach • SEP addresses power management in the residential space. • OpenADR addresses a DR approach for C&I. • Energy Interop builds on part of OpenADR, and is bigger than PAP9. It is a market oriented standard with DR signals in the context of market transactions.

  6. PAPs 3 (price&product), 4 (schedule) • The vision of PAPs 3 and 4 is to have a robust representation of price and schedule that can serve cross-domain interactions of the smart grid, whether markets, facilities, or grid operations. • PAP4 • Schedule representation based on the “schedule CIM” • PAP4 plan calls for all to contribute, and then all to implement, composed into other standards. • PAP3 • 2 track approach like PAP9: SEP, EMIX • Different focus, but they need to agree where they overlap • So, where are we with the PAPs?

  7. PAPs 3,4,9 in a development and review cycle PAP10 PAPs 3,4,9, 10 timeline

  8. Draft Specification presentations SEP2 EI WS-Calendar EMIX

  9. ZigBee Smart Energy 2PAP 3-4-9-10 SGIP MeetingPresenter: Don Sturek CTO, Grid2Home Connectivity Week – Santa Clara 2010

  10. Introduction • Presenter : • Don Sturek, CTO – Grid2Home, Inc • ZigBee Core Stack Working Group Chair • OpenSG Communications Chair • Past experience in Bluetooth, IP Networking Edge Routers, Satellite Video, Cellular handsets

  11. ZigBee Smart Energy 2Project Overview and Profile Layers

  12. ZigBee Alliance Background • The ZigBee Alliance is a non-profit vendor consortium deploying wireless mesh application profiles over IEEE 802.15.4 MAC/PHY solutions. • 360 member companies (commercial building solution providers, metering companies, semiconductor providers, utilities, integrators, etc.) • Existing standards in: • Commercial Building Automation (liaison with ASHRAE) • Health Care (liaison with Continua Alliance) • Smart Energy 1 (liaison with ESMIG, deployments in Texas, Australia and several US utilities) • Home Automation and Telecom Applications

  13. ZigBee SE 2 Profile Requirements Must source all standards from: IEEE, IETF, IEC, W3C. Where standards are not available, must propose back to these SDOs Network layer based on IP (Internet Protocol) Application layer based on IEC 61968 Common Information Model (extended to cover Smart Metering use cases). MAC/PHY agnostic (although a single wireless and single wired MAC/PHY is preferred) OpenSGOpenHAN compliant

  14. Profile Layers for IEEE 802.2 Compliant MAC/PHYs

  15. Profile Layers for IEEE 802.15.4

  16. ZigBee SE 2 Profile Standards MAC/PHY: IEEE 802.15.4, IEEE P1901, WiFi, any IEEE 802.2 compliant MAC/PHY Network: IPv6, TCP, UDP, ICMP (all IETF standards) Application Support: HTTP (REST architecture) (IETF standard), CoRE (Working Group in IETF) and W3C EXI (World Wide Web Consortium) Application (IEC 61968 CIM with XML data exchange) Security: PANA, EAP, EAP/TLS, FIPS-140-2 compliant algorithms and security suites (all IETF standards)

  17. ZigBee SE 2 Application Specification Overview • Supports business objective messages deployed on URIs, managed through HTTP (REST) • Demand Response/Load Control, Messaging, Confirmation Resource, Pricing, Pre-Payment, Metering, Plug-In Electric Vehicles, Distributed Energy Resource Control and Capability, Billing, Registration • Supports partitioning of the object model into deployment device types: • In Premises Display, Load Control, Smart Thermostats, Meters, Smart Appliances, Premises Energy Management Systems, Energy Services Interface, Prepayment Terminals, Inverters, EVSE, EUMD

  18. ZigBee SE 2 Application Specification Semantics Device Types deploy specific URIs supported by RESTfull HTTP (GET, PUT, POST, DELETE operations) Device Types implement a set of mandatory and optional business objective messages Data is exchanged using XML (based on XSDs derived from the IEC 61968 CIM partitioned into device types)

  19. ZigBee Smart Energy 2Price, Scheduling, DR/DER and Energy Usage (PAPs 3-4-9-10)

  20. ZigBee SE 2 Application Specification Example • What’s available in the SE 2.0 Application Specification out for public comment: • UML model (subset of IEC 61968, extended for the ZigBee+HomePlug MRD and Use Cases, SAE use cases, etc.) • Identification of common devices: Meters, ESIs, Thermostats, PHEV, DER, etc. • XSDs which describe XML exchanged between devices • Eg: What is out for public comment is a complete end to end proposal for providing price, schedule (price and DR) and energy usage with message exchange semantics • “Pull” mechanism from clients or publish/subscribe based on client registration with server

  21. ZigBee SE 2 Pricing Data Model

  22. ZigBee SE 2 Application Specification Example • URI for the Meter Device Type Price Resource: • http(s)://(ipv6 address)/pr • URI for specific Tariff valid for a TimeTariffInterval: • http(s)://(ipv6 address)/pr/{#} • HTTP POST, PUT and DELETE are disallowed by the server • Client HTTP GET yields the Tariff and TimeTariffInterval where either Block Tariffs or TOU Tariffs are possible

  23. ZigBee SE 2 Price Data Model Objects • Tariff • TimeTariffInterval • TOU-only • Block-only • TOU+Block • General objects: • AccountingUnit, ChangeUnit, ChangeKind, ConsumptionTariffInterval, Currency, CustomerAccount, Percent, PriceLevel, PricingStructure, Randomization, RealEnergy, ServiceClass, ServiceKind, ServiceSupplier • Energy types supported: Electricity, Gas, Water, etc.

  24. ZigBee SE 2 Price Schedule Example • Schedule is maintained on the server for the resource as a collection of events on the /pr URI • Clients may “Pull” as many events as they have resources to store (or as few as the current/next events) • Minimal requirements around schedule retention on the client was a requirement from device manufacturers

  25. ZigBee SE 2 Energy Usage Data Meter Device Type is the server for energy usage data. Meters can serve electric, gas, water or other resource energy usage Energy Usage Data pulled by the client is owned by the customer Meter requires customer authorization and mutual authentication to serve usage data. Meter is required to provide energy usage for the current billing period.

  26. ZigBee SE 2 Meter Resources Meter (mtr) Meter reading (mr) – contains both register read (r) and interval read (ir) Status (s) TOU tariff profile (tp)

  27. ZigBee SE 2 Meter Data Object Model

  28. ZigBee SE 2 Reading Type Object ReadingType object Type of data conveyed by a specific Reading. href attribute (anyURI) Hypertext reference pointing to a URI ID attribute (string) From IEC TC57 61968-9 Annex C.3.1 ============================= <ReadingTypeIDmRID> := <attribute 1>.<attribute 2>.<attribute 3>.<attribute 4>.<attribute 5>.<attribute 6>.<attribute 7>.<attribute 8>.<attribute 9> It should be noted that two of the attributes themselves are compound fields. This result is to have a Name with 11 fields: (sample values for Instantaneous demand) 1. TimeAttribute (=12 instantaneous) 2. DataQualifier (=0 n/a) 3. AccumlationBehaviour (=6 indicating) 4. FlowDirection (=1 forward) 5. UomCategorySubclass (=0 n/a) 6. UomCategoryIndex (=8 demand) 7. MeasurementCategory (=0.0 n/a) 8. Enumeration 9. Phase (=0 n/a to all phases) 10. Multiplier (=3 kilo) 11. UnitOfMeasure (=38 w)

  29. ZigBee SE 2 Meter Reading Schema

  30. ZigBee SE 2 Meter Register Reading Attribute Strings Reading Type Alias Name (SEP 2.0) ................................. Reading Type Name (CIM) ............................................................................................... 4604 ReadingTypemRID Register Readings CurrentSummationDelivered (Electric - kWh) ....................... Present BulkQuantity Forward SecondaryMetered-Energy (kWh) ................................ 15.0.1.1.0.12.0.0.0.3.72 CurrentSummationDelivered (Electric - kVAh) ...................... Present BulkQuantity Forward SecondaryMetered-Energy (kVAh) .............................. 15.0.1.1.0.12.0.0.0.3.71 CurrentSummationDelivered (Gas - m3) ............................... Present BulkQuantity Forward NaturalGas (m3) ........................................................... 15.0.1.1.0.61.0.0.0.0.42 CurrentSummationDelivered (Gas - ccf) ............................... Present BulkQuantity Forward NaturalGas (ccf) ......................................................... 15.0.1.1.0.61.0.0.0.2.119 CurrentSummationDelivered (Water - m3)............................ Present BulkQuantity Forward Water (m3) ................................................................... 15.0.1.1.0.63.0.0.0.0.42 CurrentSummationDelivered (Water - ccf) ............................ Present BulkQuantity Forward Water (ccf) .................................................................. 15.0.1.1.0.63.0.0.0.2.119 CurrentSummationReceived (Electric - kWh) ....................... Present BulkQuantity Reverse SecondaryMetered-Energy (kWh) .............................. 15.0.1.19.0.12.0.0.0.3.72 CurrentSummationReceived (Electric - kVAh) ...................... Present BulkQuantity Reverse SecondaryMetered-Energy (kVAh) ............................ 15.0.1.19.0.12.0.0.0.3.71 CurrentMaxDemandDelivered (Electric - kW) ....................... Present Maximum Indicating Forward SecondaryMetered-Demand (kW) ...................... 15.8.6.1.0.8.0.0.0.3.38 CurrentMaxDemandDelivered (Electric - kVA)...................... Present Maximum Indicating Forward SecondaryMetered-Demand (kVA)..................... 15.8.6.1.0.8.0.0.0.3.61 CurrentMaxDemandDelivered (Gas - m3/h) ......................... Present Maximum Indicating Forward NaturalGas (m3/h) .......................................... 15.8.6.1.0.61.0.0.0.0.121 CurrentMaxDemandDelivered (Gas - ccf/h) .......................... Present Maximum Indicating Forward NaturalGas (ccf/h)........................................... 15.8.6.1.0.61.0.0.0.2.120 CurrentMaxDemandDelivered (Water - m3/h) ...................... Present Maximum Indicating Forward Water (m3/h) ................................................... 15.8.6.1.0.63.0.0.0.0.121 CurrentMaxDemandDelivered (Water - ccf/h) ....................... Present Maximum Indicating Forward Water (ccf/h) ................................................... 15.8.6.1.0.63.0.0.0.2.120 CurrentMaxDemandReceived (Electric - kW) ....................... Present Maximum Indicating Reverse SecondaryMetered-Demand (kW) .................... 15.8.6.19.0.8.0.0.0.3.38 CurrentMaxDemandReceived (Electric - kVA) ...................... Present Maximum Indicating Reverse SecondaryMetered-Demand (kVA) .................. 15.8.6.19.0.8.0.0.0.3.61

  31. OASIS Work on PAPs 03, 04, 09 Energy Interoperation WS-Calendar Energy Market Information Exchange

  32. Guiding Principles • See NIST Framework & Roadmap page 48 • Additional functionality and innovation through: • Symmetry – facilitates bi-directional flows of energy and information • Transparency – supports a transparent and auditable chain of transactions • Composition – facilitates building of complex interfaces from simpler ones • Extensibility – enables adding new functions or modifying existing ones

  33. Guiding Principles (2) • Loose coupling – helps to create a flexible platform that can support valid bilateral and multilateral transactions without elaborate pre-arrangement • Layered systems – separates functions, with each layer providing services to the layer above and receiving services from the layer below • Shallow integration – does not require detailed mutual information to interact with other managed or configured components

  34. Composable Standards • For scalability • For independent innovation and evolution • With agreed interface contracts • For simplicity • For reuse • See NIST Framework & Roadmap page 48

  35. Demand Response Interoperation • Need to include • Price and Product Definition • Schedule • Load and Usage • Meaning of signals • Means of communicating • Security • Varies for different interactions • Privacy issues

  36. DR Interoperation—Composition • What to compose? • Price and Product Definition compose EMIX • Schedule compose WS-Calendar • Load and Usage compose PAP10 Core Standard • Meaning of signals in Energy Interop • Means of communicating in Energy Interop • Security compose WS-Security and more • Varies for different interactions • Privacy issues • Where do you compose? Application? Standard? • Long and short term perspective

  37. Relationships of Standards Energy Interop Schedule Price+ Product Def Usage & Load

  38. OASIS WS-Calendar TC Web Services Calendar TC http://www.oasis-open.org/committees/ws-calendar/ All committee work visible from the link email, documents, minutes, sign up for membership Comment mechanism for public comment Aiming for first public review in May 2010 To join or for more information contact chair Toby Considine toby.considine@gmail.com 38 38

  39. OASIS Energy Interoperation TC • Technical Committee Home Page • http://www.oasis-open.org/committees/energyinterop • All committee work visible from the link • email, documents, minutes, sign up for membership • Specification draft in public review now • http://www.oasis-open.org/committees/download.php/37925/energyinterop-1%200-spec-wd-12.pdf • To join or for more information contact co-chairs • William Cox wtcox@CoxSoftwareArchitects.com • David Holmberg david.holmberg@nist.gov

  40. Participation • National Labs • Universities • OpenSG OpenADR participants • Meter and Control Companies • Curtailment Service Providers • Recently joined by ISOs • California ISO • Midwest ISO

  41. Current work in Energy Interoperation TC • Refactoring of OpenADR to meet needs of both traditional DR and Transactional Energy • IncorporatingActor standards derived from NAESB work • Ensure the use cases and requirements recently delivered by NAESB are addressed • Next steps are from • Business Requirements to • Interaction model to • Information exchange to • Detailed information model and schema

  42. Interaction Patterns

  43. Interaction Patterns (2)

  44. Energy Market Information Exchange (eMIX) Technical Committee Status Report Edward G. Cazalet, Bill Cox Co Chairs Toby Considine, Editor ed@cazalet.com May 27th 2010 Download eMIX Draft Standard : http://www.oasis-open.org/committees/download.php/37959/emix-1.0-spec-wd-06.pdf

  45. OASIS Energy Market Info Exch TC • OASIS Energy Market Information Exchange TC • http://www.oasis-open.org/committees/emix/ • All committee work visible from the link • email, documents, minutes, sign up for membership • Comment mechanism for public comment • To join or for more information contact co-chairs • William Cox wtcox@CoxSoftwareArchitects.com • Ed Cazalet ed@cazalet.com 45

  46. Energy Market Information Exchange EMIX : data model and XML vocabulary to exchange prices and product definitions for transactional energy markets. Price information Bid information Time for use or availability Units and quantity to be traded Characteristics of what is traded

  47. eMIX Information Model • Intrinsic Qualities (outside the envelope) • Price & Quantity • Extrinsic Qualities (inside the envelope) • Source • source characteristics • carbon • air quality related content (i.e. NOX) • audit information • information consists of warrants, that is, assertions made by an authority.

  48. Intrinsic Elements the "outside of the envelope”

  49. Collaborative Energy Draft Standards The following drafts are in public review through June 21, 2010 (approximate date): WS-Calendar TC Energy Market Information Exchange TC Energy Interoperation TC

  50. WS-Calendar Public Review Draft The following document is in public review through June 21, 2010 (approximate date): WS-Calendar Draft Standard http://www.oasis-open.org/committees/download.php/37888/WS-Calendar-1%200-spec-wd-06.pdf http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ws-calendar for how to comment

More Related