Distributed Energy Grids can use Diverse Energy Storage

But there’s no way to store energy, he said. What he should have said is that there are few ways to store energy at grid scale. Grids, and microgrids, have two approaches to storing energy. They can store it in something that produces electricity, or they can store it in any format that provides a service to its customers. The closer we get to the end users of energy, the more options we have to store energy. The most critical short term goal of smart grids might be to transfer as many incentives for energy storage to the end nodes of the grid as possible as soon as possible.

Very few of us want electricity—we want instead to have a modern life-style. This means we want ready access to sanitary services, whether clean water or working waste disposal. We want light, and heat (or cooling). We want our appliances to provide whatever services we bought them for. Digital electronics provide us with the most direct conversion of electricity to desirable service, but even there we may be able to store services.

Behind every meter there is a microgrid, which exists to supply the wants of its customers. The customers of transmission and distribution grids only want electricity, and they want a lot, so these grids are limited in how they can store energy. Any storage that these grids do use, must be big enough to support the transmission or distribution scale of operations. For example, pump storage, wherein water is pumped up in the air, and used for hydro-generation later, is a very efficient way to store the energy in electricity for later use. Transmission-scale pump storage, though, must be as big as a small lake. There are a limited number of locations to place a lake with a down-hill water supply where filling and draining the lake is an acceptable option. We may have used all of them in North America already.

There are not many more options for distribution scale storage in traditional local microgrids. Non-traditional microgrids, however, distribute more than electrical energy. District energy grids distribute thermal energy, whether in the form of heat (steam) or of cooling (chilled water). These systems can pre-cool (or pre-heat, although this is less common) water for distribution. Thermal storage lets district energy microgrids shift energy use to off-peak hours. In a modern transactive grid, such shifting can be part of demand response. Microgrids with significant thermal storage may be able to run entirely on site-based alternative energy during peak hours. They may be able to store off-peak generation converted to thermal energy.

Non-energy utilities have their own grids supported by the distribution grid. A significant service in cities is the supply of water, and water pressure. This is done by pumping water high into the air, using energy-intensive pumps. Water towers can easily become locations for energy storage, off-loading electrical use until when energy is cheap, and the pumps can run inexpensively. This local pump storage is not used to generate electricity, but within its limits is an effective way to shift energy use to times when energy is cheaper and more plentiful.

When the microgrid gets down to the size of a single commercial building or home, all sorts of energy storage options become available, if only we do not confine ourselves to electrical storage. High rise buildings pump water to so toilets will flush. Thermal storage can be in basements or rooftops. Some data center strategies could even be considered to be storing up business process for use later.

Small standards for small things

We were discussing standards upon which to build standards today. Before systems can communicate, there is a lot of work building the platform they communicate from. So much of the small work that will be needed for the internet of things is based upon constrained communications between resource-constrained devices. I found myself spitting out acronyms right and left – a veritable techno-glossolalia

There is a whole set of standards needed by the utilities to share billing information with a third party, such as Google Energy or Microsoft Hohm. The utilities are constrained by their mandate to make all services universally available. This means they are trying to accomplish the goals they call OpenADE (Automated Data Exchange) using only the equipment they already have in homes.

http://www.smartgridipedia.org/index.php/OpenADE_Charter

oBIX is a low level (the the extent REST or SOAP is ever low level) protocol for talking to control systems. oBIX was designed as an object-oriented model from which higher level objects could be created (a process that oBIX call defining contracts). Today, all contracts are proprietary, but the work plan has always anticipated standard contracts…standard contracts currently anticipated include include WS-Calendar scheduling, Energy Interoperation, and energy profiles. Non-energy related plans include binding for RSS and ATOM.

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=obix

There is a suite of low-level pre-standards efforts to develop applications extremely constrained in resources and communications. They all seem to have names that are one-offs of 6LoWPAN (IPv6 over Low power Wireless Area Networks). Note: ZigBee pre-dates 6LoWPAN and is not entirely compatible with IPv6.

There is the compressed HTTP over PANs (CHOWPAN) recently submitted to the IETF.

http://ftp2.kr.vim.org/internet-drafts/draft-frank-6lowpan-chopan-00.txt

There is the Applications for 6LoWPAN work in the IETF, submitted by the Utilities

http://zachshelby.org/2009/07/07/6lowapp-embedded-application-protocols/

There is the new Service Discovery for 6LowApp submitted to the IETF by PGE.

http://tools.ietf.org/html/draft-sturek-6lowapp-servicediscovery-00

There is also considerable work done on discovery and profiles this summer in the OASIS Web Services Discovery and Web Services Devices Profile (WS-DD) TC. This work is subtitled “Enabling secure Web service messaging, discovery, description, and eventing on resource-constrained endpoints” Note: while WS-DP defines how to communicate a profile, it does not actually define any particular profiles—for example, an energy profile could be communicated if we knew what an energy profile looked like.

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-dd

One of the interesting aspects of this committee which had the major OS companies, the major enterprise management software companies, and the major printer companies represented, was that Schneider Electric was on board. Schneider representatives have stated that all of their switch-gear will support WS-DD and WS-DP eventually. Schneider contracted with a 3rd party to develop WS-DD and WS-DP for very small devices as an open source project. They used this project to assert (as all OASIS TC’s must) that they had successfully implemented WS-DD and WS-DP. This site can be found at the address below and downloaded under the BSD license.

https://forge.soa4d.org/

Hope this helps everyone keep caught up!

Standards for energy engagement and autonomous response (3b of 3)

The fourth of three planned posts on revisiting the smart grid priority action plans ran over long. The first post discussed semantic issues. The next addressed the conflict between the business models for Managed and Collaborative Energy. In this one, I discuss the architecturally significant interfaces of the smart grid, updating my earlier musing on SGIX. The third (3A) discussed the 4 key standards for coordinating energy use and supply. This one discusses standards for feedback and planning on the customer side.

SG Energy Usage

Energy use has traditionally been summed over a month and then received by the client weeks later, far too late to affect behavior. Recent high profile efforts by Google Energy and Microsoft Hohm have demonstrated the power of granting consumers access to near real time dynamic data about energy usage. Makers of building automation systems (BAS), particularly makers of heating and cooling systems, have long wanted direct access to current meter information. Two quite different standards efforts from two quite different trade associations are taking one standards for sharing energy usage information.

OpenADE

The UCA International user’s group (UCAIug) is developing OpenADE (Automated Data Exchange) to more readily share information through existing utility infrastructure. It begins with sharing day old interval data with customers and third parties, and will then strive to become more current. OpenADE leverages the standards of Managed Energy (described in my previous post). Although the long term plan is cloudy, surely the utilities are well poised to include demand response (DR) and other grid and market events with usage information.

EISA

The Energy Information Standards Alliance (EISA) is a new consortium considering energy usage from the perspective of the end node. EISA foresees much more frequent and timely information not only from the meter, but also from each intelligent system and appliance throughout the building. Each system will provide a type of energy metadata on systems that consume power. Think of the Google Energy demonstrations, think again of certain contributors to the energy profile able to report and to identify their own use.

One part of the EISA vision that appeals to me is the idea that autonomous building systems would compare energy profiles and smooth the overall load profiles; no two systems would produce energy spikes at the same time. Autonomous load shaping is important not only for the short term grid, but is also an important enabler of site-based energy, and even net zero strategies. Some members of EISA see it as a suite of standard oBIX contracts.

Standards Ancillary to Energy but useful to Smart Grids

Many of the benefits of smart grids come from improved situation awareness. The standards used within the grid itself, which I do not concern myself with, are largely to improve awareness of grid operations. Where I do concern myself, with the end nodes of the grid, those situations and that awareness reach beyond the grid itself.

UnitsML and SensorML

There are many things to be measured and sensed in industrial facilities and commercial buildings. Sensors may be part of systems or isolated. (I have some use cases that demand incorporating ancillary sensors into central energy management.) It would be good to use standards that describe the measurements unambiguously in ways that can be shared by multiple systems.

UnitsML offers an unambiguous way to describe all physical measurements, and an unambiguous ability for a computer to look up the translation of any units of measure to any other units. UnitsML is an existing OASIS technical committee with NIST backing which will need wider participation to complete.

SensorML is a standard from the Open Geospatial Consortium that can describe the geometric, dynamic, and observational characteristics of sensors and sensor systems. There are many different sensor types, from simple visual thermometers to complex electron microscopes and earth observing satellites. SensorML can describe them all.

Digital Weather Markup Language (DWML)

Knowledge of the future is important to all markets; knowledge of future weather is important to energy markets. All weather is local. Local weather awareness includes not only weather predictions, but also knowledge about the actual weather at my location following previous predictions.

DWML is an existing specification developed by the National Oceanic and Atmospheric Administration (NOAA). NOAA offers access to their National Digital Forecast Database (NDFD) using DWML. DWML is a little quirky, and a little hard to use. Smart energy would benefit from its further development. We need to define a DWML profile for reporting as well as forecasting, to enable the exchange of actual conditions as well as forecasts. Such a profile would be used when querying local weather stations and even personal weather systems.

WS-DD and WS-DP

Device discovery and device profiles have been used in computer networking for some time. These specifications for the web services implementation are going to a standards vote in May. A major manufacturer of electrical equipment has already announced that they will include WS-DD and WS DP for all the equipment it sells. There are open source implementations for small devices (https://forge.soa4d.org/). I think they will have a big role in the future world of distributed generation and Net Zero Energy facilities.

SG CyberSecurity

Cyber security is drawing more attention and concern every day. Today’s grid cybersecurity is concerned primarily with defending the isolated system with relatively static interactions. Tomorrow’s cybersecurity will apply to systems interacting with others owned by many different people, of uncertain skill and diligence in securing their own systems. Security issues need to be integrated within every smart grid standard from the beginning. We need a separate security toolkit/framework, perhaps a profile from current fine-grained security standards, key management, and related areas. Broader integration of physical security, fine-grained networking and commercial security, and situation awareness technologies need to be part of the mix.

Two Paths to Smart Energy in DC (2 of 3)

This is the second of three planned posts on the outcome of the conference last week in Virginia. The first post dealt with semantic issues. This one addresses business model issues. The third will be my perspective on critical standards, updating my earlier musing on SGIX.

Standards can seem dry and uninteresting, but they find vital expression in the business models they support or prevent. One of the underlying issues in the initially contentious smart grid meeting last week was the conflict of business models. This can be resolved, but only by talking clearly about the purposes and motivations behind each model. A good first start would be to give them good names.

Regular readers know that I favor something looking like pure market interactions. I believe that we all use a standard abstract presentation for scarcity and value, for risk and for reliability. We call this abstraction money. As Stephanie Hamilton opined when she still worked at Southern California Edison (SCE), every brown-out is a pricing failure.

Because I come from the perspective of building integrators, I have great faith in the ability of building automation systems to manage change, They are usually poorly maintained, and poorly understood by their owners, but they keep running. They adjust naturally to the conditions around them, and to their own operations, and are getting better at autonomous action and tuning. I want to give them clear price signals, not only now, but for the future. UI want to give them clearer information about weather and environment. And then I want to leave them alone.

But such systems can cost thousands of dollars to install. In part this is because without standards, they are all custom work. Still, there must be a less expensive solution.

Early smart grid deployments are aimed at the smallest, cheapest systems that can fit easily into appliances and home thermostats. They must not change the price of appliances materially, especially as social equity concerns mandate that low income consumer have access to the benefits of smart energy. Consumers want reliable systems; it is hard to convince them to pay more for systems that can be turned off by someone else.

Utilities often refer to this group as the Residential option, When pressed, they may call it ZigBee, because that trade association is the primary technology used to install these low end systems. They may call it the OpenHAN (Home Area Network) approach, although the information and interactions are indistinguishable from those of ZigBee. Sometimes this approach is used I small commercial buildings as well.

Rather than call them the OASIS or C&I (Commercial & Industrial) approach and the ZigBee or Residential approach, I think we should name them according to their business models. I propose that we call them Collaborative Energy and Managed Energy.

There, without out of the way, I can summarize succinctly the business model agreement from the customer-oriented standards development meeting.

We agreed that we would apply the semantic models coming out of NAESB to parallel processes for Collaborative and Managed energy, and that we would keep the semantics aligned when we could.