After two years of work, the market interfaces of smart energy are ready for development of the systems that will use them to begin. In smart grid, we often refer to the grid and its end nodes. The end nodes today are the commercial buildings, industrial sites, and residences that today merely consume energy.

Smart energy transfers responsibility for energy volatility to the end nodes, along with economic incentives to adjust to that variability. Energy use has long been cyclical in aggregate, with summer afternoons, especially, requiring far more energy than summer nights. The capability for power generation has been controllable, to at least come close to match this cyclical use. Renewable energy resources are not so controllable, and today often produce peak power when consumers do not need it. The growing mismatch of power supply and energy use is what drives the creation of the economic incentives

With the price of energy rising, the value of those incentives to the owners and operators of the end nodes will soon grow. Building efficiency will help a building weather peak prices, but will not help the building take advantage of the low prices that come with peak supply. That is where the market interfaces of smart energy come in.

The first one that you will hear about is Energy Interoperation. The OpenADR alliance is building OpenADR 2.0 around the OASIS Energy Interoperation standard. Energy Interoperation defines patterns of market signals for exchanging information product price and availability. A smart building system will be able to query its supplier about the market rules, and then begin to bid into that market. Buildings will listen for program-based events (Demand Response or DR) through the same family of signals. Energy Interoperation is nearly done, and goes out for a second public review this month.

Of course, market signals don’t matter unless you can understand the product being offered, and offer your own products to the market. Price and Product for power markets are defined by the Energy Market Information Exchange (EMIX) specification, which is currently in public review. EMIX is defined in three schemas.

1. The first, EMIX, creates a general information structure products and contracts for commodities whose value varies with the time of delivery. EMIX also includes information to indicate market requirements, such as a minimum notification time.
   
2. The second, POWER, defines market information for power and electrical products built upon the core EMIX information elements.
3. The third, RESOURCE, defines specific capabilities of systems inside buildings, either singly or in aggregate, that affect their ability to provide products to the market. Resources are defined using the information models from the EMIX and POWER schemas. Dispatch-based markets can use RESOURCE to automate market decisions.

EMIX was built in tiers so it can support multiple energy markets. Other Energy distribution markets can use the same market constructs. Natural Gas markets can vary with pipe pressure and demand. District Energy thermal markets, including high pressure steam, low pressure steam and chilled water have similar needs. By defining schemas for each based on EMIX, just as POWER is based on EMIX, markets for these energy sources can be transacted over any Energy Interoperation-based system, including OpenADR. Such schemas are not part of EMIX 1.0, but they are already being discussed.

[an error occurred while processing this directive] Underlying both these standards is a common communication of time and interval-or what we call them together, the schedule. Production, consumption, supply, and price, or buyer and seller have schedules generated by their own means. WS-Calendar provides a common language for discussing these schedules. This language is used in EMIX, and used in Energy Interoperation. Developers of systems for vehicles and for building systems are discussing using WS-calendar to exchange information about their needs and use as well.

Participants form the largest software companies, who make the largest enterprise calendar systems are exploring the use of WS-Calendar as well. Because it is built upon iCalendar, there are scores of proprietary and open source implementations already in development. The Bedework Open Source calendar project is already demonstrating direct use of this specification.

Building systems must understand their own energy use, and how to change it to take advantage of these specifications. Sometimes the right thing to do is to increase  energy use, to take advantage of low-priced power, to avoid its use later.

The specifications are relatively stable, and ready for demonstration use. The companies that start now, will be the first to new national markets that do not rely on customization for each territory.

Gentlemen, Warm up your coders and start your Smart Energy Engines….

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]