Coordinating Time and Energy

Buildings use 46% of the energy used in North America. Consensus guesses are that buildings could reduce their energy use by a third while improving the amenities they offer, by becoming enterprise-responsive without other change in technology. Clearly the most basic enterprise interaction is what is the schedule for each room, and how many people will be using the room.

The best guesses are that half of the electricity generated each year in the North America is wasted due to poor alignment of generation and consumption. The way to align the behaviors of these two groups, each autonomous, and each with quite different values is price signals. As each price signal, and each energy contract, would include a schedule component, we need a standard way to discuss schedules in web services for power negotiations.

17% of North American generation is used for less than 110 hours per year. Utilities want to manage the consumption patterns using a process they refer to as Demand-Response. Demand Response always has a scheduling component. It would be nice to use the same xml object for buildings, energy markets, and demand response. Add in weather arbitrage for distributed generation and more domains need to share common scheduling information.

So I went looking for a calendar standard for web services I could use. I as surprised not to find one. I am looking for a small "micro-specification" that would not exist on its own, but would be incorporated into other specifications. I call this WS-Calendar. I want to keep WS-Calendar (or whatever) small as I think that we can get it off the ground and completed quickly. oBIX has gotten about half way there, but I fear a component of a control system standard will not be picked up elsewhere (for social reasons).

oBIX needs it because a significant component of enterprise responsiveness is letting building systems easily receive scheduling information from business programs. Most of us regularly invite 7 people and a room to a meeting. If the "room calendar" could inform the building systems to be ready on time, and to ventilate for 8 people, more efficient operations would result. We have all been in conference rooms that are freezing with 4 people in attendance, and sleepy when 15 are in attendance...

There are some remaining issues in such a standard. Do I put my performance contract inside the Calendar (as a meeting is) or outside but within the same payload? Would I refer to one, or several, oBIX contracts from within the Calendar? Could contracts refer to one or several calendar items? It seems to me that the same issues would come up if the calendar was part of a BPEL, or part of OpenADR, or even part of WSDM.

Watch soon for discussion prior to the formation of the WS-Calendar Technical Committee in OASIS. And drop me a line if you want to participate, or if you have other use cases you want to share.

Working with the Wind in Chicago

Chicago has long been known as the windy city, for its promises of its politicians and the quantity of its conventions and conferences. Next week, there will be a lot of wind surrounding the AHR Expo, the largest conference anywhere dedicated to the efficient movement of air, and thereby the biggest energy-related conference of the year. Numerous engineering and energy related conferences and meetings will be in town to take advantage of the more than 50,000 attendees. I, too, will be blowing into town, giving some talks, participating in some meetings, and planning still others. This may be the last time I am in Chicago until March, so drop me a line to schedule a meeting if you want to discuss plans or alignment while I am there.

The GridWise Architectural Council (GWAC) has put together several sessions as part of an AHR conference track explaining the mission of the GridWise Alliance and opportunities created by the smart grid. On Monday, I will speak on academic energy initiatives, their problems, and their promise. Many academic leaders have signed the American College and University President’s Climate Initiative, committing their institutions to change how their schools are operated in ways that are verifiable and repeatable. Unfortunately, these efforts often are characterized more by proper feelings than by proper actions, and the results are often poor. Examples abound of efforts such as the Oberlin College Lewis Center, designed to be a net zero building, yet actually producing poor performance for years before retrofits finally delivered on its promise. Other green initiatives, including some at the University of North Carolina, have made performance worse. Efforts that address only new buildings using new standards without providing for cost effective inclusion existing buildings will have little effect.

This session will provide an overview of the initiative and its participants. I will discuss existing and developing standards for making building operations and energy use visible beyond the confines of the traditional campus maintenance and operations organization. I will describe efforts to make building operations responsive to the academic and research activities, and how these actions interact with growing campus concerns over security and emergency awareness. A clear understanding of these issues is needed for any college and university to meet these goals. A clear understanding of the problems and developing standards will help the energy professional compete and perform better in this market. These same knowledge and skills apply to the challenges of new national energy initiatives and will help the professional respond to anticipated Obama federal infrastructure programs.

On Tuesday, also at the AHR show, I will be teaming up with Ken Sinclair, editor of the Automated Buildings e-zine, to aim a little farther out. We will discuss the vision of interactive buildings as full participants in the smart grid. Building-to-Grid (B2G) interactions will create whole new business models outside buildings. Developing communication standards between building and grid will make the economic consequences of each operating decision visible. These communications will be critical to the development of Net Zero Energy (NZE) buildings. Economic service interactions will create new markets for building-based equipment and new models for building system integration. Come to this session to learn what these new markets will look like, and how today’s system designs are changing to prepare for them.

On Wednesday and Thursday, I will join a couple of Department of Energy (DOE) summits on the new standards. Wednesday afternoon, the B2G Summit will bring together an impressive group of thought leaders in technology and policy to brief the HVAC and BAS industry on the business opportunities from the smart grid. The conversations between and after sessions at the Summit are always as informative and useful as the sessions. On Thursday, the DOE Commercial Building Energy Alliances have announced their own summit for HVAC, Refrigeration, and Controls Suppliers. The summit will focus on retrofitting existing buildings. The summit will address all products related to energy efficiency in buildings, except for lighting. Drop me a line if you want to catch up with me at either of these events or to schedule a discussion on how these standards might work into your plants.

The activity I am personally most excited by, however, is meetings to plan GridEcon. GridEcon will explore the economic and market requirements of the smart grid. None of the smart technologies I write about will be adopted without a firm basis in economics and markets. The primary benefit of informational interoperability in building systems and in smart energy systems will be the creation of dynamic markets, markets that reduce technological friction and reward innovation. GridEcon will take advantage of the great Chicago-based markets in commodities and weather, and of the technologists behind their trading systems, to help create the market rules we will need. Watch for future announcements of this conference which will be in Chicago in mid-March.

See you in the Windy City!

A pricing Service for Electricity

What price structures are necessary to enable fully symmetric negotiations over power purchase and sale? Over at the NIST TWIKI, Marty Burns, Bill Cox, and I ironed out the requirements for a pricing service for electricity. Comments are welcome.

---

What are the requirements for communicating price across the smart grid? What pricing structures are in use or under development now? How do we move to a common information element, common whatever else needed for prices?

Note: It is important to emphasize that these are requirements for a solution set for pricing services. Therefore all the following requirements are not necessarily simultaneously applied to any particular single service based on the ensuing model.

Due to potentially [rapidly] changing roles, we use the terms supplier and consumer rather than utility and customer. With aggregators, these terms are still more general.

This page was created and modified by Marty Burns, Toby Considine, and William Cox, for discussion among the DEWGs.

Pricing Requirements

Dynamic pricing enables dynamic power management and includes both:

1) the realtime response of automation systems to "realtime" grid pricing and

2) the managed response of consumer management and planning systems to supplier/grid price forecasts.

1.1 Regulatory/Policy

• 1.1.1 Metering, Billing, and Collections are separate processes / services from power delivery.
• 1.1.2 Aggregation and Delegation should be explicitly permitted for all operations.
• 1.1.3 The pricing model is not explicitly tied to any particular regulatory environment.
• 1.1.4 Barriers to symmetric operations should be eliminated.
  • 1.1.4.1 Suppliers and consumers may exchange roles at frequent intervals.
• 1.1.5 Businesses willl handle traditional business processes as they do now.

1.2 Business Objectives

• 1.2.1 Suppliers are able to provide automated dynamic pricing information to consumers.
• 1.2.2 Pricing is able to support active power management and optimization.
  • 1.2.2.1 Price adjustments can be made in time in up near real time manner.
  • 1.2.2.2 Prices may include commitment enforcement in support of a variety of scenarios, including both minimum and maximum commitments.
• 1.2.3 Pricing should be available for a variety of deliverables.
  • 1.2.3.1 Power Consumption.
  • 1.2.3.2 Peak Availability.
  • 1.2.3.3 Relinquishment of prior right (Differential Behavior vs Absolute Consumption).
  • 1.2.3.4 Power Quality.
  • 1.2.3.5 Carbon Offsets.
  • 1.2.3.6 Transmission and Congestion.
• 1.2.4 Pricing should support the decommoditization of power.
  • 1.2.4.1 Wind, Distance, Carbon, Triple Bottom Line, and other attributes.
• 1.2.5 Pricing should be time sensitive.
  • 1.2.5.1 Time offer made.
  • 1.2.5.2 Window for offer.
  • 1.2.5.3 Time of acceptance.
  • 1.2.5.4 Scheduled Time of consumption.
  • 1.2.5.5 Actual Time of Aggregation.

1.3 Business Procedures

• 1.3.1 A set of core processes and transactions will be defined.
• 1.3.2 A service to support each core process will be defined.
• 1.3.3 A common service framework will be defined to support all services.
• 1.3.4 Market operations should support unidirectional price announcements.
• 1.3.5 Market operations should support bidirectional bidding.

1.4 Business Context

• 1.4.1 Legacy pricing models need not be supported by the new interfaces.
• 1.4.2 Legacy business processes need not flow through new interfaces.
• 1.4.3 Requirements to continue traditional business processes may be met outside of the new interface.

1.5 Semantic Understanding

• 1.5.1 Must accommodate wide range of Pricing Models.
• 1.5.2 All Pricing Models should contain a common set of properties.
• 1.5.3 Many Pricing Models may be in effect concurrently.
• 1.5.4 Pricing Models will change over time and must be discoverable.

1.6 Interaction Model.

• 1.6.1 All intereactions will be messaging based.
  • 1.6.1.1 synchronous request-response pull.
  • 1.6.1.2 asynchronous publish-subscribe push.
• 1.6.2 Symmetry should be supported at all interfaces.
• 1.6.3 Best Efforts message delivery shall be supported.
• 1.6.4 Security and Privacy must be designed into the model.
  • 1.6.4.1 Authentication is often required.
  • 1.6.4.2 Guaranteed message delivery shall be supported.
  • 1.6.4.3 Non-repudiated message delivery shall be supported.
  • 1.6.4.4 Private message delivery shall be supported.
• 1.6.5 Delegation of message handling shall be supported.

Smartgrid Basics: The Demand Side Problem

Last week the Smartgrid-discuss group opened up within OASIS, introducing power grid technologies to the architects of e-commerce and internet security standards. Some of the latter are trying to understand the problem, and learn the jargon. I wrote this as the second of a series of posts introduce the issues in a simplified, almost cartoon form.

Building systems have traditionally been invisible and uncontrollable. They have been managed to reduce costs with no real focus on the service they are providing. They have grown up in sandboxes, using their own peculiar protocols. These protocols are deep and technology specific, and often without effective interface. These systems are operated, when they are operated by process specialists.

Building occupants rarely have a precise understanding of how these systems affect their business. They may know exactly what a too-hot or too-cold call costs. They know that tenant dissatisfaction may lead to un-renewed leases. They may suspect that under ventilation may lead to sleepy occupants, but can rarely put any exact price tag on that. This makes them conservative about making changes in building operations.

Demand Response (DR) is emerging a critical tool for dealing with peak load management. Peak loads are by far the most expensive and dirtiest electricity we have; their costs, on both bottom lines, swamping others. Demand response is moving from direct control to economic incentives, but underneath, today’s integrations are process centric rather than service oriented. Energy providers order or pay energy customers to turn off things on just a few days a year, to manage the peak. We encourage only the crudest, least effective energy savings, while denying the market the energy signals that would cause better.

At the commodity system level, DR is already moving to services and agents. Agents defend their own mission while responding to the outside world. Washing machines know not to respond to grid signals until they determine that the current laundry is not soaking in bleach. Refrigerators know not to respond if they have just finished a defrost cycle. These systems know and understand what services they provide and so are ready to be responsive. Building systems are not.

We will get larger DR when we talk to the building occupant. We will get better participation when the occupant remains in control. The occupant will not allow DR when the in-laws are coming for the weekend. The occupant knows the family overspent at Christmas and is willing to respond to any and all incentives. The access control system may know that only three people on the fourth floor came to work today. Human resources knows that the sales force is on a retreat. Together, they can choreograph far greater response from the building systems then ever will be permitted as an automatic response from control communications.

Demand Response must be about economic signals to a business entity. When thought of in this way, there is no need for different signals to Industry and to Business (and to home and to vehicle). The business may choose to automate this. The business may benefit from templates for response, whether developed by EPRI or by ASHRAE, which reduce the risk of considering participation. These choices and these templates are not part of the interface.

The interface should not does not concern itself with the underlying technology and control protocols. It should not be based upon BACnet, or OPC, or LON any number of other low level control system protocols. The interface must be one that enables business decisions. Control systems should offer up service interfaces for choreographed response. Whatever offer and counter offer DR requires, whether amount of load shed or maximum load used or time to respond must be in the interface, but no deep process.

The smartgrid to building/industry/home interface is about how the Service Oriented Building can respond to the Service Oriented Grid. Just as in other services, the underlying processes should be hidden.

If you want to join the public discussion at OASIS, send a message to smartgrid-discuss-subscribe@lists.oasis-open.org.