Underpinnings for standardizing Demand Response (DR)

For decades, regulated electricity markets have struggled to deal with volatile energy markets providing to support un-caring customers. Customer’s real-time purchases, called load by the electricity industry, vary throughout the day, and more to the point, co-vary with external events. These issues are not limited to electricity. The “Super-Bowl flush”, which has reached the status of urban legend, names the stresses placed on urban waste water systems as external events synchronize demand.

Public Utilities Commissions defined tariffs to prevent the Super-Bowl flush for decades. Peak use can increase prices for a year. Tiered pricing increases the bill for any amount above a pre-set usage during a month. These approaches pre-date any discussion of smart grid—often they have effects contrary to those desired by the smart grid. The smart grid is smart in that it detects at any time whether there is too little or too much power available, and uses market signals to decrease or increase demand to match supply.

Early efforts at the smart grid focus solely on reduction. When the signal goes out to certain buildings, they reduce their load, or use of electricity, in a pre-defined way. We call this process demand response, and pre-eminent specification for this signal is called Open Automated Demand Response (OpenADR).

Demand response must be more than load reduction. The great wind farms of west Texas, the most successful farms in North America, are, I’m told, able to sell less than 40% of the electricity they generate. The wind generates electricity at times when no one is planning to use it. Even the most inefficient energy storage would be preferable to simply wasting the electricity.

The challenge now is to define signals that common across North America and the world, and that that handle energy surplus as well as deficit. This effort is underway in the OASIS Energy Interoperation Technical Committee.

One problem is that energy market operations have been restricted and confined, both by technology limitations and by public policy decisions. We have discussed DR as a one-way interaction, from utilities to customers. We have tied DR to special tariffs and to direct control systems. Each of these restricts the participants and innovation in DR.

On the Committee, we tried to place electricity in a normal market context. We identified four essential market activities, or services:

1. There is an indication of interest (trying to flush out offers), when a market operator is seeking partners for a demand response or energy source.
2. There is an offer of a service whether megawatts or “nega-watts”
3. There is an execution of a contract (agreement to purchase / supply (b))
4. There is a call for performance of the contract (c) at the price agreed upon.

We are defining these services so they can be combined to meet today’s tariffs. For example, one of today’s tariffs for interruptible power may offer a lower price all year in return for the right to shed load automatically up to six times a year. Under the Energy Interoperation model, this would be standing contract with 6 time-limited pre-executed response contracts. Automated Demand Response is merely a call for performance on existing contracts at the agreed upon price.

Another model, coming into use, is Price-based ADR. If we assume the traditional utility-centric model, we would see the utility publishing an indication of interest in buying DR at a given price. Business and buildings willing to respond would simultaneously offer and execute a contract to shed load. The performance could be called at the same time or later as contracted.

Emergency or "Grid Reliability" events could look left out by this approach. Grid Reliability events require mandatory participation in today’s markets. These could be set up as standing pre-executed options. A grid operator then need merely call for performance as in any other demand-limiting event.

In this way, we can build all the tariffs and markets out of a few low-level services.

Sometime soon, I will write about the requirements for a pricing service.

Smart Buildings & Smart Energy: the Integration Challenge

Last week, twenty of us gathered in DC for a two-day charrette on the standards needed to apply BIM to the problems of dynamic energy management. The work-shop, entitled “Smart Buildings, Smart Energy”, was put on by the Corps of Engineers Research Lab (CERL) at the National Institute for Building Science (NIBS). The meeting was a fascinating, and occasionally heated conversation that brought together academic and government researchers, building system practitioners from industry leading companies, and participants in standards committees from ASHRAE to OASIS. It was a fascinating meeting, filled with bright, deeply focused individuals who as a group had not yet recognized the profound changes in their goals required by smart energy.

The challenge of smart energy to buildings is dynamic change. The goal of smart buildings has always been superior performance—usually defined as energy efficiency. Energy from external sources will all become dynamic and intermittent. Some will be available under rapidly changing prices. The most efficient system may not be the one that is most able to respond to these changing conditions. Perhaps the goal of smart buildings is to defend its occupants from the degraded conditions of the smart grid. The game is changing.

The use of Building Information Models (BIM) is only now becoming common enough to change business processes. BIM lets us design buildings the way we design cars and planes, with full simulation and testing before the contractor turns over the first shovel full of dirt. BIM furthermore provides the contractor with accurate materials requirements and each trade with accurate measurements. With better knowledge and a dramatic reduction in re-work, the cost of construction can come way down while the quality goes up.

Most of the cost of a building is incurred in operations, during the long period between construction and demolition. For the last five years, led by NASA and CERL, there has been a project to define how to hand over information from design and construction for use in operations. The Construction Operations Building Information Exchange (COBIE) defines how to hand over information from the BIM to maintenance and operations.

The information in COBIE seems almost trivial—unless you don’t have it. COBIE defines a standard exchange for equipment information including spare parts lists and preventive maintenance schedules. COBIE exchanges are defined as a series of simple spreadsheets, which can be generated from BIM or filled in by hand. A growing number of maintenance management systems are now able to import COBIE directly into their databases. Whether or not a building was built using BIM, whether a building is old or new, the owner can request COBIE formatted information for handover from the builder, commissioning agent, or seller.

Francois Grobler gathered us together to discuss how to extend COBIE to reduce the cost of building system integration. Building systems are classically islands of automation, communicating only with a single proprietary console. The cost and time required for integration is a barrier both to better integration, and to system upgrades. Occult system tags and poor documentation prevent the timely value-based upgrades that drive innovation in the IT world.

This last point is critical of we are ever to get to a highly innovative green-tech. Cost-based upgrades look to historical cost and to growing maintenance problems to decide when to upgrade. Systems are not replaced until they fail or have been completely depreciated. As IT merged with telecommunications, we moved to value-based upgrades. Lap-tops and PDAs are upgraded when they give the sales force a competitive edge. Work-stations are upgraded to increase engineering productivity. This dynamic has driven these worlds to innovate to drive shorter sales and replacement cycles. The difference is the one between the old black hand-set we used to lease from the phone company, often for decades, and the new market of cell-phones and the latest functions.

A key component of this new COBIE will be control system tags and metadata. Today, a retro-commissioning agent spends the first days or even on site in low-value discovery of this information from blue prints and the current control system. Only after this work is complete, can the more high-value and useful work begin. When a project such as completed, those working notes are thrown away, or stored where they see no further use. A standard for the exchange of this information would reduce the costs of each commissioning and perhaps stimulate a market for third party discovery tools.

Space is the most important class of metadata. People in buildings inhabit and interact with spaces. Building systems affect those spaces, and secure those spaces, but the relation between systems and space is often occult. BIM can provide the mapping, but we don’t need all the BIM for that. We need something small and lightweight, describes the three dimensional space, but leaves out the details that add complexity.

The most significant use of BIM will be in buildings that built without using BIM. Most buildings next year are not new; most new buildings next year will be built without using BIM. Even if we were to imagine that in five years, all buildings will be built using BIM, most buildings still would not have a full BIM, with an intelligent structure, for a very long time. Fortunately, we do not need a full BIM to describe the space in buildings, and to provide a light framework integrating system information with that space.

Retro-BIM is the work for taking one of today’s buildings and creating a BIM for a portion, usually during a renovation. These BIMs tend to be descriptive, and lack the full engineering detail that would come with design through BIM. There is a growing set of tools and practices to cost effectively create a three-dimensional BIM during a renovation. Retro-BIM can provide as good a foundation for a light integration framework as can a full design BIM.

Green Building XML (GBXML) was designed to provide a “good enough” description of building space and building systems to support energy models that are “good enough”. GBXML is based on the IFC data models that underlie design BIM. Because GBXML already includes information on space and systems in a light-weight model, GBXML would need only a little extension to map system tags and related system metadata to space. Retro-BIM datasets, design to map to the IFCs, should be able to expose information as GBXML with little trouble.

The new challenge of smart energy is dynamic decision-making. Volatile energy availability and energy prices will make the grid  an unpredictable supplier. The availability of on-site energy sources, both generation and storage, enable self-reliance. Smart energy will require energy use decisions on a minute by minute basis. Buildings must be able to accept the complexity of new systems and new technologies without bearing the additional cost of complex integrations. GBXML might be the shim between systems, space, and the people that occupy that space that lets us put it all together.

Doing things at the right time

I have been writing too much elsewhere to write as much as I’d like here recently. WS-Calendar, EMIX, and EnergyInterop all have drafts out for comments this week. Standards specifications require a lot of coordination to get into publication.

Last Sunday, the WS-Calendar Technical Committee released a draft for comments. This is a small component among standards, but one that can help integrate building systems into the businesses that inhabit them. Already there are early attempts to integrate this specification into energy, into the enterprise, as well as into building operations.

I couldn’t make it through a week without using the IETF standards iCalendar and its supporting communications tools iMIP, iTIP, and calDAV. I am thankful for the many hours they save me every week. I think you may feel the same way, too.

What, you say? You don’t think about these standards? Well, that’s because they are ubiquitous, they work, and are therefore invisible. You use them to schedule meetings, and webinars, to remember plane travel and hotels reservations. They are everywhere, they work, and so we don’t talk about them.

WS-Calendar builds upon these specifications to bring schedules and synchronization to web services and inter-process communications. We created WS-Calendar to create, share, invoke, adjust, and track coordinated response between domains and organizations. By domains, I mean different groups that speak different languages. WS-Calendar will see use in financial instruments and building systems, in energy markets and in enterprise systems, in PDAs and electric cars.

Of most interest to automated buildings readers is how it affects building systems, and what new opportunities it opens up there. Years ago, when became chair of the oBIX TC (Technical Committee), I observed that the BAS needed to know the schedule of the conference room. My corporate calendar already knows when meetings begin each day, when they end each day, and how many people are in each meeting.

There is already a rough draft to incorporate WS-Calendar into oBIX, the OASIS web services standard for communicating with building systems. I have discussed use of WS-Calendar with many members of the BACnet community. It is likely that both communities will soon be able to use this specification to communicate with their respective building systems.

We can expect that enterprise systems will soon support this information sharing. Apple, Microsoft, and Oracle all participated in the WS-Calendar process. I have heard of a trial use of WS-Calendar directly from a Microsoft Exchange server. The makers of registrar’s office software, used to schedule college classes, are looking to communicate class schedules, and the number of students in each class, directly with the building systems.

Smart grids and demand response are everywhere in the news today. Smart grids communicate energy shortages and surpluses to the end nodes of the grid: buildings, homes, and industries. New standards for energy market communications include WS-Calendar. Through WS-Calendar, Energy, Enterprise, and Buildings communicate in a common language to discuss when and how to perform.

WS-Calendar is based on a suite of documents, all currently seeking comments. xCal defines a standard way to render iCalendar information in XML. CalWS is a web service standardizing the API for Calendaring & Scheduling functions on any platform supporting calendaring. WS-Calendar is the component for inter-domain communications.

Comments on WS-Calendar can be posted using the comments link at http://www.oasis-open.org/committees/ws-calendar/

Its almost here – and time to start planning how to use it.

Punch and Judy and Energy Usage

The collection and display of energy usage information is a hotly contested area of smart energy standards. This small, seemingly obvious issue has generated more fights than all other issues, and more open political involvement. One model sees the utility collecting energy usage information and sharing that information later the customer or his designees. The other model sees the meter as an information appliance on the premises, just one of a number of real time information sources for demand side management.

For now, visibility is all. Up-to-the-hour energy bills on the web, and on our web-connected smart phones, are the first generation. This is a short-sighted goal. Mere energy charts on-line will not hold the consumer’s attention. Over time, consumer will go back to looking at other thing on the ‘net, or perhaps even occasionally be off line. Long term benefits will come from complete information models that spur completion to automate energy use decisions in response to the wishes of the consumer.

The real contest is over control of the customer interface, and thereby of the customer. Today's Google Energy and Microsoft Hohm pose no threats to the control of the customer by the utility. The utilities still can gate access to the back-end energy markets. Control of energy information prevents both intermediation and disintermediation in the energy market. Utilities also are desperate to justify their AMI investments at a time when many are calling for moratoriums and delays in deployment; AMI is part of a seamless model that includes control of the customer’s home as well as of access to information.

Each side in this debate is beating the other with a privacy stick. The CPUC has received complaints about non-resident (but bill-paying) consumers accessing usage information from the web. (A Berkeley student did not want Mom and Dad to find out that she spent her weekends elsewhere than in the apartment they were paying for.) The way ZigBee systems are usually installed by the utilities often grants access to nothing or everything, and the wireless mesh covers entire townhomes and apartment buildings; utilities argue that direct access could let you view your neighbor’s data.

Energy communication standards surrounding usage need to address four areas:

1. What data is available to consumers? The short term need is usage visibility. Thereafter, the need is to support agents able to optimize the total home or commercial building experience. These agents will also compete to support zero net and off grid energy use, where the grid has minimal, or no effect. The utilities information model is not rich enough to support this.
2. What clear language describes the energy used? Usage semantics begins with the Power and Load Management Common Information Model (IEC TC57 CIM). Consumers need other information including environmental aspects of energy choices, such as pollutants per kWh.
3. Where is the source of the information? The utilities communication infrastructure will always limit the timeliness and frequency of utility-centric communication. Information directly from the meter is more timely and detailed, but lacks historical context. We must accommodate both.
4. How is the information accessed? Historical information stored at the utility requires less operational security, but requires the most attention to consumer privacy. Information delivered from the on-premises meter to drive system decisions can be more complete but may vary from final billing. Data used by service providers to operate buildings requires both privacy standards and integrity guarantees.

The UCAIug has developed an application, OpenADE, that can provide near term access to information using today’s grid infrastructure. OpenADE is good enough to support the first generation systems. OpenADE is neither timely enough to support real-time operations nor an adequate information model for future applications. The standard must acknowledge the limited information models available from OpenADE.

The EIS Alliance had developed a larger information model to support tomorrow’s applications. The Alliance sees the meter as an information appliance for the consumer’s premises. The Alliance has proposed standards to put the consumer in control, while reducing integration costs for premises equipment. Live, well defined information exchange provides a platform for competitive technology markets.

The challenge for today is to ensure both backward compatibility with OpenADE and today’s infrastructure and forward compatibility with the unimagined future. That future will support disruptive business models as well as technologies. And that’s why the fights are so fierce over something that appears so simple.