Smart Grid Schedule Approaches

Explanation and Background of Smart Grid Schedule Approaches

Date: December 29, 2009
By: Toby Considine, University of North Carolina at Chapel Hill
To: Various Discussion Lists

Explaning why the WS-Calendar TC proposers chose iCalendar for time synchronization of the smart grid.

There are two quite different time-related tasks: time synchronization and schedule alignment. As those who grew up like me watching Mission Impossible know, every episode begins with synchronizing the watches. What they actually do during the show/mission is alignment based on that synchronization. Performance alignment introduces the most interesting plot twists to the show; performance alignment is also at the heart of several of the most important issues of smart grids. Either is useless unless time synchronization has occurred already.

PAP13 is primarily involved with issues of time synchronization and PAP04 with alignment.

The tasks of performance alignment and many and varied. There will be a DR event at 3:15 today. In 6 hours, the price will be half of what it is now - and will stay there for three hours. I would like to buy power with this power profile during the 6 hours beginning with 4:00 next Tuesday. For a list of the smart grid schedule alignment use cases developed by NAESB, look to:

http://www.naesb.org/pdf4/smart_grid_ssd121709w3.doc

Performance alignment is not only a concern to smart grid issues. Smart grids need to align and coordinate response off of the grid. Buildings should respond to the scheduled alignment. Business processes should be reviewed to understand if the response makes sense to the business. Financial instruments need to allow for the purchase and sale of energy resources available only in small windows, whether that window is immediate or in the future. Just as the incentive for participating in smart energy must be understood across domain boundaries (dollars) so the time interval that is the focus of the decision must be understood across domain boundaries. This is why we have reached out to the group, the Calendaring and Scheduling Consortium (CalConnect) that works with enterprise schedules and calendar interactions to define the common element of scheduling and interval management.

It is inaccurate to say that "we have chosen iCalendar for the smart grid" (iCal is an application that happens to run on a Mac. iCalendar is a standard that defined within the IETF process to communicate meetings and events). It would be closer to say that we have gotten the folks who shepherd the iCalendar standard *and others related to schedule alignment* involved in defining common schedule and interval elements to use for discussing schedule and interval across domains within service oriented architectures. We plan to use the new components (which are not iCalendar, but start with iCalendar and other well-known elements) as the basis for all inter-domain communications on interval and schedule in smart grids as well as other business and consumer activities.

Just as the smart grid did not begin in January 2009, or with EISA 2007, the analysis, outreach, and engagement that resulted in CalConnects leadership in this area have been ongoing for some time. To enable enterprise response in buildings, the oBIX TC has been looking to schedule elements to align services in buildings and enterprises since 2004. OBIX dropped efforts to create its own elements because we felt that a standard coming from the Enterprise would get better acceptance than the other way around.

There were detailed conversations in this area in January of 2008. During an symposium on BIFER (Building Information for Emergency Response) at NIST in the Fall of 2008, a core of us recognized a similar need there. There are many overlaps between the interaction patterns of Demand Response and of the CAP Alerts of emergency response. Some Demand Response is already distributed using EDXL under CAP (Common Alerting Protocol). The first description in my notes naming a common schedule and interval communication for Buildings, Emergency Response, Enterprise, Governmental Affairs, and Personal response as WS-Calendar was from October 2008.

By the AHR show in January 2009, at which there was a DOE B2G summit, CalConnect was actively working on normalizing the semantic elements of ICalendar, of preparing a CIM for Schedules and Events that could support this schedule component. The results of a teleconference that week were shared with representatives from DOE, NIST, and the GWAC.

As the roadmap developed in Summer 2009, this direction was reinforced. At the end of the summer, CalConnect finished working an extensible definition of ICalendar through the IETF process, creating RFC 5545, the Internet Calendaring and Scheduling Core Object Specification. At the end of the summer, the Smart Grid process designated NAESB as the representative of the Electricity industry to prepare use cases to test and validate the development of a semantic model and web services component that expresses the core object for service interaction. This is the work that will be done as a joint effort of CalConnect and OASIS.

Once the committee starts, all OASIS work is available on the web as soon as it is published for the committee. Comments on any OASIS committee's work can be contributed through the comments list server — those comments themselves are instantly available in the public archives. Only time and attention, the two most non-renewable resources, are needed to participate at that level.

Prepared by Robin Cover for The XML Cover Pages archive. See details on WS-Calendar in the news story: "OASIS Web Services Calendar (WS-Calendar) TC to Create Common Scheduling Standard."

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	Smart Grid Schedule Approaches Explanation and Background of Smart Grid Schedule Approaches Date: December 29, 2009 By: Toby Considine, University of North Carolina at Chapel Hill To: Various Discussion Lists Explaning why the WS-Calendar TC proposers chose iCalendar for time synchronization of the smart grid. There are two quite different time-related tasks: time synchronization and schedule alignment. As those who grew up like me watching Mission Impossible know, every episode begins with synchronizing the watches. What they actually do during the show/mission is alignment based on that synchronization. Performance alignment introduces the most interesting plot twists to the show; performance alignment is also at the heart of several of the most important issues of smart grids. Either is useless unless time synchronization has occurred already. PAP13 is primarily involved with issues of time synchronization and PAP04 with alignment. The tasks of performance alignment and many and varied. There will be a DR event at 3:15 today. In 6 hours, the price will be half of what it is now - and will stay there for three hours. I would like to buy power with this power profile during the 6 hours beginning with 4:00 next Tuesday. For a list of the smart grid schedule alignment use cases developed by NAESB, look to: http://www.naesb.org/pdf4/smart_grid_ssd121709w3.doc Performance alignment is not only a concern to smart grid issues. Smart grids need to align and coordinate response off of the grid. Buildings should respond to the scheduled alignment. Business processes should be reviewed to understand if the response makes sense to the business. Financial instruments need to allow for the purchase and sale of energy resources available only in small windows, whether that window is immediate or in the future. Just as the incentive for participating in smart energy must be understood across domain boundaries (dollars) so the time interval that is the focus of the decision must be understood across domain boundaries. This is why we have reached out to the group, the Calendaring and Scheduling Consortium (CalConnect) that works with enterprise schedules and calendar interactions to define the common element of scheduling and interval management. It is inaccurate to say that "we have chosen iCalendar for the smart grid" (iCal is an application that happens to run on a Mac. iCalendar is a standard that defined within the IETF process to communicate meetings and events). It would be closer to say that we have gotten the folks who shepherd the iCalendar standard and others related to schedule alignment involved in defining common schedule and interval elements to use for discussing schedule and interval across domains within service oriented architectures. We plan to use the new components (which are not iCalendar, but start with iCalendar and other well-known elements) as the basis for all inter-domain communications on interval and schedule in smart grids as well as other business and consumer activities. Just as the smart grid did not begin in January 2009, or with EISA 2007, the analysis, outreach, and engagement that resulted in CalConnects leadership in this area have been ongoing for some time. To enable enterprise response in buildings, the oBIX TC has been looking to schedule elements to align services in buildings and enterprises since 2004. OBIX dropped efforts to create its own elements because we felt that a standard coming from the Enterprise would get better acceptance than the other way around. There were detailed conversations in this area in January of 2008. During an symposium on BIFER (Building Information for Emergency Response) at NIST in the Fall of 2008, a core of us recognized a similar need there. There are many overlaps between the interaction patterns of Demand Response and of the CAP Alerts of emergency response. Some Demand Response is already distributed using EDXL under CAP (Common Alerting Protocol). The first description in my notes naming a common schedule and interval communication for Buildings, Emergency Response, Enterprise, Governmental Affairs, and Personal response as WS-Calendar was from October 2008. By the AHR show in January 2009, at which there was a DOE B2G summit, CalConnect was actively working on normalizing the semantic elements of ICalendar, of preparing a CIM for Schedules and Events that could support this schedule component. The results of a teleconference that week were shared with representatives from DOE, NIST, and the GWAC. As the roadmap developed in Summer 2009, this direction was reinforced. At the end of the summer, CalConnect finished working an extensible definition of ICalendar through the IETF process, creating RFC 5545, the Internet Calendaring and Scheduling Core Object Specification. At the end of the summer, the Smart Grid process designated NAESB as the representative of the Electricity industry to prepare use cases to test and validate the development of a semantic model and web services component that expresses the core object for service interaction. This is the work that will be done as a joint effort of CalConnect and OASIS. Once the committee starts, all OASIS work is available on the web as soon as it is published for the committee. Comments on any OASIS committee's work can be contributed through the comments list server — those comments themselves are instantly available in the public archives. Only time and attention, the two most non-renewable resources, are needed to participate at that level. Prepared by Robin Cover for The XML Cover Pages archive. See details on WS-Calendar in the news story: "OASIS Web Services Calendar (WS-Calendar) TC to Create Common Scheduling Standard."