Ready for the BSI

I want to get back to buildings soon. Smart grids are engaging, but I think our goals for the future will be met by buildings.

For months, all my writing has been about smart grids. More particularly, for November, it has all been about smart grid standards.

As I write this, the essential market interfaces of the grid are in review. A common communication of schedule and interval, suitable for sharing schedules between grid and enterprise and building and finance finished public review last Tuesday. We have nearly 80 comments to settle, but soon we will be ready to discuss using ws-calendar not only in smart grids, but in buildings.

Energy Market Information (EMIX), the critical description of energy product and price has two more weeks for public review. Energy prices always have a schedule, and EMIX uses WS-Calendar. EMIX supports demand response, but more importantly, full participation of buildings in all energy markets. EMIX is in review until the 17^th.

Energy Interop was released for public review last Saturday. EI (as we call it) defines the essential e-commerce framework for interactions between grids and aggregators and utilities and, yes, buildings. EI is locked for review until December 27.

Now, I am reeling from a week at Grid-Interop, at which I have spoken 5 times, sat In two meetings of the Smart Grid Architectural Committee, and practiced politics (difficult for me) in numerous other meetings. In October and November I put three of the four market interfaces of the smart grid out for public review. Light, loose, market oriented, interfaces that transfer incentives for participation to the buildings. Now I am longing to talk of buildings again.

Today, at Grid-Interop, the focus shifted to buildings as microgrids, each responsible for managing energy use, generation conversion, storage, and, only as a last resort, market operations to make up the difference. This is what I wanted to accomplish when I got started on Smart Energy. No grid control, which would strangle in-building innovation. Maximum grid incentives, all delivered to a single energy services interface (ESI), the locus of market bidding for the building.

Now I turn back to the building, Now I want to think of the Building Systems Interface (BSI), the abstract interface to building systems. Some of it is building services as in BAS, abstracted with system metadata, and associated with the space it supports, the space that the tenants recognize. Some of it is simple appliances, and the way the communicate in homes. Some of it is the live or plug load, perhaps discover able, perhaps mappable to space using PLie.

So what are the essential building services? There is energy management, accessible for low integration re-hosting in the clouds, There is performance contracting, also in the clouds. There is energy auditing, which must be based upon the zero integration costs (because the metadata is already in the BSI). Energy auditing? Well what if we call it a live LEED rating, or perhaps 3^rd party verification of the performance of the performance contractors… BIFER (BI for emergency responders) may even come from that mix.

There is an enterprise service, that links between the occupants and their activities and the BAS and its performance. It communicates to support business activities while using the common schedule communications developed for smart grids. It is aware of the market conditions and deals made with the grid though the ESI. It knows whether the volatile energy of the renewables-based grid is scarce or abundant. It can report back to the enterprise how and where energy is being used right now.

This needs some standards to fly, to be cheap enough to let these cloud-based services flourish. PLie needs to be advanced to a standard. oBIX trends for energy management must be accessible form self-metering systems and from switch panels, and be able to support the NAESB Energy Usage Information standards. There must be a light-weight BIM, my vote is for GBXML, able to act as the spatial lens through which to view energy use.

I want to define the BSI…

But now, rest, and sleep.

Coming to Terms with EMIX

Another of the essential inter-domain standards for smart energy is being released for formal public review this week. Schedule, price & product descriptions, market interactions, and usage reporting are the standards to enable arms-length interactions between participants in smart energy. When these are stable, products that need them can come out of the labs, accelerated by common communication standards across the country. The miracle of software, silicon, and scale can begin to work its magic to balance energy supply and demand, in a world where both are more volatile than today.

EMIX, or Energy Market Information Exchange, supports market communications concerning energy. At first glance, this would appear to be a simple commodity market, with a simple product, power. Energy, however, is the most volatile commodity. Pork-bellies and wheat can be stored. Fresh produce must be used in season. Energy must be used when available, its shelf life is moments, and its cycle of seasons is completed every day. This need to coordinate precise delivery and availability times makes traditional market communications inadequate.

Energy surpluses and shortages are known in advance, at least as much as they are for other commodities. The periods are much tighter. Commodity markets price produce based upon weather during the long growing season. Secondary weather markets let investors hedge against rain during, say, soybean harvest week in Indiana. Alternative energy markets will compress the same business processes into a single day. Timing is everything in energy.

Energy use does not exist in a vacuum; it intersects with the businesses and lives that inhabit buildings and venues, and those are managed by on-line calendars. Business meetings, weddings, soccer games, and concerts are all schedules using iCalendar-based communications. WS-Calendar extends iCalendar interactions to support the needs service oriented inter-process communications.

EMIX calls the application or product definitions to schedules “Terms”. EMIX uses WS-Calendar to express schedule based information as part of product definitions. The complexity of operations schedules, and weather predictions, and market availability are reduced to schedules and prices. Whether a market is closely regulated with invariant tariffs or whether a market is dynamic and vital, the software and equipment in those markets will receive the same messages, the EMIX Terms.

Terms may be incomplete during indications of interest and tenders, may be firmed up by purchases or executing options, and may be only completed during specific calls for performance. EMIX does not pre-judge how Terms are completed, nor create market rules for their elaboration. EMIX does not dictate market rules. EMIX terms express the results of market operations and market rules, and the schedules of energy supply and demand, and the schedules that they create.

In all markets, there is more variety of appetites and needs then there are of contracts. In Real Estate, initial indications of interest may specify neighborhoods, or the number of bathrooms, or even cities with specific demographics. Over time, the deal becomes focused, the specifics become concrete, and the actual closing, even in a creative transaction, is expressed in a mundane manner.

In an analogous way, EMIX can express resource capabilities for buyers with specific needs, or for sellers seeking to find a market. The Terms of offers can be made as expressions of capabilities and requirements, applied to the schedule of how those vary over time. Other offer terms may be as specific as the final performance call.

EMIX supports more than Power markets. By describing ancillary services, it can help distributed resources find more markets in which to sell. It describes transport charges, which might enable consumers to select their energy supplier. EMIX provides the means for warrants of energy source and environmental cost to travel with the transaction. That, however, is a longer story.

Energy Market Information and Schedules

This post describes my attempts to use the OASIS specification WS-Calendar as a component of EMIX. WS-Calendar specifies how to share schedules and sequences in web services. EMIX (Energy Market Information Exchange) provides price and product descriptions for products that vary over time, including electrical power. Both standards are currently in development.

Electric energy has seasons of abundance and scarcity as do agricultural commodities. Electric energy’s seasons are measured in days instead of in years. EMIX uses WS-Calendar to describe products whose supply and value change rapidly over time.

Five KW at 2:00 AM is not the same product as Five KW at 2:00 PM. EMIX describes products for which time, the interval in which it is delivered, is an essential attribute. For energy purchases made in consecutive intervals, prices and quantities may vary for each interval. EMIX describes products for which a key characteristic is variance over time, whether the product is generation or load reduction, wind or coal, power or regulation.

For the simplest product, the dispatch of power, EMIX is simply a product description (constant power), a start date and time, a duration, a quantity, and a price. If the rate and price have been set in advance, the dispatching communication might be simple “start at 3:00 (reference uri to product), for 45 minutes.”

It is often desirable to discuss a sequence of intervals in which to purchase electric energy. In any set of intervals, most information would be redundant. The same product could be described again and again, once for each interval. Only a few characteristics, perhaps only price, or quantity, might change per interval. EMIX specifies product information once, and then specifies only the changes in each interval.

Some energy products have characteristics that present a consistent pattern over time, whenever purchased. A generator may run at half speed for an hour while warming up. A responsive load may require 15 minutes before load reduction. These characteristics may hold true whether generation or response is requested for 15 minutes of 15 hours. EMIX specifies these invariant characteristics as part of a product, while offering the variable run-time to the market.

The EMIX Product Description specifies the characteristics of a product at a given instant in time. The EMIX Product uses WS-Calendar to express how that product varies over time. WS-Calendar describes how a single specification can be shared between a sequence of time intervals, and a gluon, which describes aspects of the specification shared by all, including, perhaps, the schedule for the sequence. WS-Calendar also another gluon can associate with the another gluon to influence a gluon-sequence information set.

A sequence could also have 10 consecutive 15 minute intervals, each with a different quantity (or different price). Rather than expressing a product description, a start date and time, a quantity, and a price, 10 times, EMIX uses a gluon associated with the sequence, letting you put the product description, start date and time, and price in the gluon, and have only the quantity in each interval.

If a market rule stated that there was no price for a ramp period, the first interval could have a price of zero. In that case, that first interval could have a price of zero (blocking the price coming from the gluon). All other intervals could get the price from above.

The same override capabilities go to any variable. If the ramp periods have a fixed time, but the run time is variable (describing a typical generation resource, and perhaps most DR assets) then the duration can be expressed in the gluon, inherited by all intervals that themselves do not have a duration, i.e., the generation load, and ignored by those that do, i.e., the ramp times.

But the simplest (one price, one time, one interval, one duration, one amount) explicit invocation, and the simplest implicit (do that thing, one time) invocation are still invoking the EMIX Product, consisting of a Gluon holding a Product Definition, Start Time, and a sequence.

What buildings have to say to smart grids

The challenges of smart energy are well known. How can we as a society based on cheap plentiful always available energy, adapt to shortages, intermittent availability, and a continuing shortage of capacity to move energy from where we make it to where we want to use it. Local shortages and outages will become the norm, although local surpluses might create greater challenges. Most importantly, how can we adapt without abandoning the life-styles that we enjoy, and that we hope our grandchildren can as well.

The national Priority Action Plans (PAPs) for smart grids and smart energy aim to accelerate development of enabling specifications for smart energy. Most look solely to the internal operations of the electrical grid itself. These activities, while important, can only enable the innovations we need; electrical grids themselves will not be the basis the most important changes.

Others PAPs look to extend grid operations into our lives. PAP11, for example, looks to control and track personal vehicle use in service to the grid. We are not willing as a society to assume our position as cogs in the machine. Utilities and policy makers see this as the happy efficiency of well-ordered future; the public instead sees the dystopian factory of Chaplin’s Modern Times. Perhaps we should be glad that while other action plans focus more on openness and change, this activity is being developed under a veil of trade secrets and inside pool that will only speed the early failure of its model.

The newly formed PAP17 launched the ASHRAE SPC (Standard Project Committee) 201, Facility Smart Grid Information Model. SPC 201 offers a consumer-centric model that can support the rapid changes in the ways we use and manage energy. The focus is on how the systems in buildings can interact to create what grid operators call Distributed Energy Resources (DER). Building-based DER addresses the intermittent shortages and outages of the smart grid directly.

Traditional grid-building interactions use direct control. Turn this off, turn this on, to support the needs of the grid. PAP17 assumes the economic communications of price and availability developed by the market-oriented PAPs, and considers what a building needs to communicate internally so it can be mature market participant.

If each building has its own portfolio of DER, sun, wind, perhaps limited pump storage offered for voltage regulation, batteries, ice, load shedding….That building may use a different suite of internal responses each time it sells a response to the grid. Market participation becomes based on reliably producing a change in power use rather than turning on and off a device. If SPC201 fails, it will fail by failing to embrace this economic model, and letting its engineers revert to a model of direct dispatch by the grid.

A distributed energy resource (DER) may be:

1. A private asset of the building, used only for the buildings purposes, perhaps when the grid is unavailable, and not revealed to the grid at all
2. A component of a building’s demand response, so turning off the chiller or turning on the generator are indistinguishable to the grid
3. An intermittent asset of building with availability characteristics which are *may* be revealed to the grid, i.e., the grid operator may contract to know whether it is sun or wind, so the operator may better estimate when it can be relied upon
4. A building asset that happens to be operated by a third party. That party *may* happen to be a traditional player, perhaps one called a “utility”. It could just as easily be an ISO, depending on scale and location. Or it could be some new form of energy service provider
5. Owned by the building but effectively leased to the grid operator, and treated as a forward deployed asset of the grid
6. Owned and operated by a third party and used as a forward deployed asset of the energy services provider

(4, 5, 6) are the ones that look like direct dispatch as we understand it today—but they need not be. Whether the grid sends market signals that are flash traded to negotiate individual contracts for use of DER, or whether that contract is pre-executed, actual use of that DER is best thought of as a call for performance on the contract. Third party service providers will pay better for guaranteed response, and will demand greater penalties for non-performance when a high service level was promised.

During the National Roadmap efforts in 2009, we used the catch-phrase “Every end-node is a microgrid”. A microgrid is responsible for meeting its own needs and purposes by managing its own energy use, generation, storage, recycling, and market operations to deal with surplus or deficit. Note that the market operations are last. Microgrids are defined recursively (as per Galvin): A suite in a building or a production line could be a microgrid. The office park or campus could be a microgrid containing the building microgrids.

At ConnectivityWeek last May, heard a speaker from the DOW described his big goal that every building be able tolerate 8 days of grid down-time with no loss of amenities. Contemplating this requirement suggests what a poor partner the smart grids will be. SPC201 is reaching toward the information sharing that equipment and systems in buildings and homes will need to support us despite smart grids.

If there is a flowering of Green-Tech, it will come from consumer based markets that can tolerate rapid innovation and change. Those markets will require low integration costs based on loose coupling and energy information sharing.