OASIS Energy Interoperation TC Meeting Notes
July 1, 2009
TC Member Attendees in Bold: (Sorted by First Name, Last Name, and Company)
First Name / Last Name / Company / Member StatusAnto / Budiardjo* / Clasma Events, Inc. / Voting Member
Craig / Gemmill / Tridium, Inc. / Voting Member
David / Holmberg / NIST / Voting Member (Co-Chair)
David / Wilson / Trane / Voting Member
Ed / Koch / Akuacom Inc. / Voting Member
Edward / Cazalet / The Cazalet Group / Voting Member
Ernst / Eder / LonMark International / Observer
Evan / Wallace / NIST / Member
Francois / Jammes / Schneider Electric / Observer
Gale / Horst / Electric Power Research Institute (EPRI) / Observer
Girish / Ghatikar / Lawrence Berkeley National Laboratory / Voting Member (Secretary)
Hans / Aanesen / Individual / Member
James Bryce / Clark / OASIS / Observer
Jane / Snowdon / IBM / Voting Member
Jeffrey / Kegley / Tridium, Inc. / Observer
Jeremy / Roberts / LonMark International / Voting Member
Kyle / Meadors / Drummond Group Inc. / Voting Member
Larry / Lackey / TIBCO Software Inc. / Voting Member
Mary / McRae / OASIS / OASIS Staff Contact
Mary Ann / Piette / Lawrence Berkeley National Laboratory / Voting Member
Matt / Wakefield / Electric Power Research Institute (EPRI) / Voting Member
Michel / Kohanim / Universal Devices, Inc. / Voting Member
Mike / Truskowski / Cisco Systems, Inc. / Voting Member
Pim van der / Eijk / Sonnenglanz Consulting / Observer
Rik / Drummond / Drummond Group Inc. / Member
Robert / Dolin / Echelon Corporation / Voting Member
Robert / Stayton* / Individual / Voting Member
Robin / Cover / OASIS / Observer
Sharon / Dinges / Trane / Member
Timothy / Bennett / Drummond Group Inc. / Voting Member
Toby / Considine / University of North Carolina at Chapel Hill / Voting Member (Co-Tech Ed.)
William / Cox* / Cox Software Architects LLC / Voting Member (Co-Chair)
NOTE: Full attendance is available online if maintained: Go to the event notice (http://www.oasis-open.org/apps/org/workgroup/energyinterop/event.php?event_id=24217 ) then click “Track Attendance” at the top (http://www.oasis-open.org/apps/org/workgroup/energyinterop/manage/track_attendance.php?day=22&event_id=24217 )
Agenda:
1. Call to Order (David Holmberg)
2. Approve minutes of previous meeting (http://www.oasis-open.org/committees/download.php/33097/EnergyInterop%20Minutes%2020090622.doc)
3. Update on liaison plans and IEC/UCA discussions on OpenADR (Bill Cox, David Holmberg, Mary Ann Piette)
4. Work plan review (Bill Cox) (15 Minutes)
a. Review TC Charter deliverables (http://www.oasis-open.org/committees/energyinterop/charter.php)
b. First steps: review of OpenADR Client Interface and Context (vocabulary)
5. Walk through CEC/LBL OpenADR Specification v1.0 Client Interface and Context (Ed Koch, Mary Ann Piette) (15 minutes) (http://www.oasis-open.org/committees/download.php/33260/cec-500-2009-063.pdf)
6. Issue collection and discussion (20 minutes)
7. Specific work items (Bill Cox and David Holmberg) (20 minutes
a. B2G: input on NIST roadmap and section 4 use case diagrams; how can that be made useful for our work
b. Plan for first Committee Draft based on 1.0 of OpenADR Report
c. Other work items
8. Adjourn
Minutes:
1. Call to Order (David Holmberg)
§ Bill: Dave was unable to attend, will be here next week – Bill Cox chaired his responsibilities
§ Bill: Sent slides for meeting
2. Approve minutes of previous meeting (http://www.oasis-open.org/committees/download.php/33097/EnergyInterop%20Minutes%2020090622.doc)
§ Bill: No quorum for approving meeting minutes. Will be considered next week.
§ Bill: David joined at 8:17 a.m. and we now have a quorum. No objections to previous meeting minutes. June 22, 2009 meeting minutes approved.
3. Update on liaison plans and IEC/UCA discussions on OpenADR (Bill Cox, David Holmberg, and Mary Ann Piette)
§ Bill: NAESB – Marketing and transmission aspects of North American (NA) energy. Also do wholesale gas and electric. They have 6 month cycle of update of their entire work. This entire work is approved by Federal Regulatory Commission (FERC).
§ Bill: Met on Monday with NA Energy Standards Board (NAESB) and David on liaison plans. Bill will put-together summary notes sometimes in future. NAESB is not much aware of OpenADR and OASIS. It was an open and learning discussion.
§ David: NAESB was thinking of sending comments on NIST SG roadmap and where NAESB stands on OpenADR and vise versa.
§ Bill: David or he will send a LHF URL list to be posted.
§ David: NAESB concern--Now that OpenADR is a recognized standard by NIST on the LHF list, what will happen to NAESB standards?
§ Bill: Other liaisons. Work going on Zigbee and other areas. To some extent, they’re extension of DR and price signals. Work has not started in this area
§ Bill: Third area of overlap in EI work is IEC, which does much of standardization in electrical energy areas. Liaison discussion started and initiated by OASIS within IEC groups. OASIS liaisons could be at TC, member section level, and at OASIS level and is little different from IEC where common liaisons are at TC level. OASIS as an entity tries to establish such relations. IEC TC 57 may be appropriate. IEC is extremely interested in formal process for OpenADR. IEC would like to establish common format for working with OASIS. The best way to liaison is to establish joint projects.
§ Mary Ann: Worth talking to some people. It’s important to recognize that both IEC TC 57 (Greg Robinson) and 8 (Richard Schomberg) are interested. The challenge is to identify key TC within IEC. Ed and she spent some time talking to Jeremy McDonald of SCE. We need to formalize this with IEC.
§ Ed: There are lot of ongoing discussions on how this is going to be structured within IEC and OASIS.
§ MAP: Because of NIST SG work, people are trying to accelerate IEC work.
§ David: NIST is planning a workshop for SDOs in August. Since OpenADR is part of it, it would be worth considering liaisons work in this workshop.
§ Bill: It is a good idea. Ed can talk a little about UCA and OASIS harmonization.
§ Ed: UCA used to be called Utility Communication Architecture now some people call it Utility Communication Association. Open SG committee within UCA and OpenADR TF is part of it. There is an F2F meeting in Columbus, OH in July. One of the things we intend to do is to bring experts from other standards groups, 61850, CIM, OASIS, MultiSpeak, C12, etc. Some of them overlap with domain space of OpenADR. The question is where do they overlap? Don’t intend to talk about administrative work. Understand the technical aspects of where are the overlaps.
§ Bill: This is furthering the work that NIST would like to accomplish in August workshop.
§ Ed: Yes, that’s possible. UCA meeting focus specifically on OpenADR.
§ Bill: is this public meetings or a conference available to participate?
§ Ed: Tele conference is available. Will check on in-person participation. Meeting on July 15, 10-12 p.m. local time People need to be registered. UCA is a stickler on who the member and who is not. The meetings are fairly large audience and there is no formal attendance taken with members attending many TF meetings.
§ Bill: Put an action item for Ed to send information on UCA meetings to TC. Bill has his participation in the calendar.
§ Bill: Identified areas of people that need communication. Some such as UCA are open; some such as NAESB is $8000-9000 membership before we can see their work. Zigbee is committed to move SEP work to IEC by 2012.
§ Rish: Zigbee SEP 2.0 requirements documents were made public recently by Zigbee Alliance. SEP 2.0 is available and information will be posted to TC.
4. Work plan review (Bill Cox)
a. Review TC Charter deliverables (http://www.oasis-open.org/committees/energyinterop/charter.php)
b. First steps: review of OpenADR Client Interface and Context (vocabulary)
§ Bill: Slide 4 is the list from Charter. We talked about models and terminology and specifications. Would like to focus on near-term items to make immediate progress.
§ Slide 5: Make relative contributions in OASIS formats. Ideally done by Technical Editor and we need another co-editor to Toby Considine. Please contact Dave, Bill, or Toby.
§ Work going on B2G and other relevant areas to look into models and specifications for standards.
§ Next week committee-draft 1. Process involves working drafts. Committee drafts will go through 60-day public review process, comments are addressed in formal way with all comments made and addressed to.
§ Open Building Information Exchange (oBIX) is a TC specification and multiple implementations would be one of the many TC could consider. For OASIS standards, it is recommended for interoperability testing. Once approved, it cannot be forwarded for adoption to international SDOs without interoperability testing. We need to think on conformance and interoperability as we move forward.
§ Identify what are our near-term works, convert them to OASIS format, vote on them as TC draft, and continue to work on draft while soliciting their inputs. Comments welcome.
§ Dave Wilson: If thinking of OpenADR and how much we adopt it. Are we taking the whole thing first and work on parts of it or parts of it and then build on it? This is his first time in OASIS activities.
§ Toby: There are two things and both go together. Ed will go on the first part. I urge people to think about this process. There are some specific parts that we may sub-committee out. Such as calendar, synchronization could be put out and added as they come in.
§ Dave Wilson: Has more experience working with Texas (TX) real-time pricing (RTP) model. Would like to see simple implementation first and then see difficult parts (bidding, etc) can be done later. Will share some of the TX work with TC.
§ Bill: We’re looking at really broad strokes. Looking at parts of the document and it’s not immutable.
§ Toby: Any other body of work that should be part of core body of work for the standards process? (None responded.)
§ Action item on maintenance is added to chat.
5. Walk through CEC/LBL OpenADR Specification v1.0 Client Interface and Context (Ed Koch, Mary Ann Piette) (http://www.oasis-open.org/committees/download.php/33260/cec-500-2009-063.pdf)
§ Mary Ann: Ed will go through the document. If anyone has questions after, we would be glad to help.
§ Ed: Hope people at least have the document. Will talk at high-level and talk about specific areas that people can consider. Start with pg. 34, figure 4 and 5. This will give the flavor of main components and interfaces. This is just a recommendation and personal opinion.
§ Bill: Will ask the TC group for specific recommendations.
§ Ed: On pg. 34, most of the use cases are instilled in these two diagrams. There are two entities interacting with DRAS. DRAS is not physical, but a logical entity. It could be a separate entity or part of utility infrastructure.
§ Bill: Many things are done by aggregators. Can they have DRAS?
§ Ed: Aggregators can have a DRAS and can communicate with end-point clients. On LHS is the utility and RHS is the customers in form of humans performing tasks. The Client is the automation piece that will process information.
§ Ed: On next page (35), those interfaces are classified as functions. The document is laid out to address these three interfaces, various data structure to perform functions by the interface. The utility/ISO functions as interface to DRAS are intra-system functions. Those interfaces don’t need to be supported by DRAS. We can envision that some third-party implementation can send information without interfacing with utility/ISO functions. These interfaces and functions are the one we should be mostly thinking about. This is 1-1 integration.
§ Ed: On DRAS client functions, many vendors and participants will be listening to messages from one entity. These are intra-system communications. If we separate the data models and filters and not focus on utility interface areas, we can save a lot of time.
§ Ed: The DRAS client functions are the most important as that’s where vendors use most and invest effort to consume those messages. The participant functions are important those who build GUI to the customers. Those who implement it will provide web-portal to the customers.
§ Bill: Are these XML interoperation functions and those could be done via GUI? They could be candidate for standardization as well in the first phase.
§ Ed: Yes, they are correct. It’s likely that someone need to provide them to the customer as they will not likely build them on their own. Some of the things on the left-side may not be important. Some are important such as opt-out, which is an important function to provide. Some of the data entities may not even be in use. Some of the participant functions are core functions to enable participation.
§ Dave Wilson: What are opt-in or opt-out process at automated level? Currently, there are phone calls and humans involved.
§ Ed: Two levels where this could be specified. There is a notation of DR programs and tariffs and one can participate in multiple programs or tariffs. When information is received, it’s specific to one program information. If someone can’t participate in any programs they can opt-out such as black-out. In addition to DRAS client interface, the DRAS client can also send information in other forms. It’s informational of operational that they would like to opt-out.
§ Ed: Trying to give a little perspective on what’s going on between the interfaces. There is a table on pg. 13 that will direct where to focus on. We need to focus on sections on row (line) 2 and 3, with 2 being the important one.
§ Rish: Few section links show “0” and are correct in Word. Will post the PDF with corrected links.
§ Ed: Chapter 5 is essentially looking at requirements and use cases. Chapter 6 sections look at data elements with diagrams and texts and have ER diagrams that are conceptual. Chapter 7 looks. Chapter 8 has API’s. Rish mailed out the zipped copies of XSD and WSDL files. Chapter 9 looks different interfaces on DRAS client. This supports multiple ways to deliver information to the client; one is via simple REST, simple SOAP, and BACnet interfaces. In future, we could add OPC, IEC, or Zigbee SEP, etc. Chapter 10 discusses security and what the philosophy for security would be.