Sharing Energy Information within the End Node

Customers and/or their energy management systems require live energy usage information to help make decisions in response to grid-centric events such as DR, curtailment, and energy market events. Energy sales and purchases are the basic elements of transactional energy; a common shared understanding of each energy use proximate to the operating decisions that influence energy use is essential to collaborative energy on the smart grid.

The target of smart grid communications, particularly in collaborative energy space, should always be the microgrid. Some microgrids may contain a single home, or commercial building, or and industrial site—those are irrelevant details. Microgrids have a number of systems inside them that must work within the economic environment of that microgrid—and I am thinking of old economics, before the distinction of economics and ecosystem arose. Some microgrids may have a single entity inside, say a traditional siloed BAS (Building Automation System), but the unitary microgrid is merely an artifact of the way we have always done it. The energy services interface is the gateway to a microgrid.

Shared responsibility for balancing energy production and consumption requires shared access to information about energy markets and actual use. Shared information on energy use, especially live energy use, is essential to cooperation between the grid and its end nodes. Each end node may have multiple systems. Those systems may have multiple strategies and approaches to managing energy. Each strategy may have unanticipated effects on the other systems. These effects can occur quickly. Unambiguous feedback and continuous monitoring are essential to deliver results while providing services to the building occupants. The official recorder of market transactions is the electrical meter.

Energy use is more than net use for a period. Load shape matters. Multiple systems may each be operating efficiently, but in ways that their aggregate effect requires more energy use than anticipated. Systems within a building should be able to share their energy use, and their anticipated energy us with each other. Load shaping within a building is a critical pre-adaptation for site-based generation and energy storage. Load shaping is necessary for multiple systems to coexist within a minimal fixed energy budgets. The ability to function within a fixed energy budget reduces the risk and thereby increases the value of site based energy sources.

Microgrids contain collections of systems that may not share common technology. Some of these systems are small, self contained, and serve special purposes, such as appliances. Some are large and complex and span significant space, such as HVAC or an industrial line. Some look alike, are built from the same components, but have different missions; the laboratory fume hood and the air conditioning system are run for different purposes and have different constraints. Some may rely on different energy markets to do the same work; heat may come from electricity, gas, or solar thermal in the same building. Some systems may store generate energy used by other systems. All of these coexist in the ecosystem of the microgrid.

Shared energy usage information is essential to interactions between:

• Distribution and the industrial, commercial, and home premise.
• The service provider and the industrial, commercial, and home premise.
• Distributed energy resources and all other domains
• Plug-in electric vehicles and premises and the grid

Any other interactions that will cause, use, or track energy transactions on smart grids.

Building revenue meters and intelligent systems in buildings should share their energy usage information in real time within the end node in a clear, accessible standard.

A Microgrid of One

The target of smart grid communications, particularly in collaborative energy space, should always be the microgrid. Some microgrids may contain a single home, or commercial building, or and industrial site—those are irrelevant details. Microgrids have a number of systems inside them that must work within the economic environment of that microgrid—and I am thinking of old economics, before the distinction of economics and ecosystem arose. Some microgrids may have a single entity inside, say a legacy BAS (Building Automation System), but the unitary microgrid is merely an artifact of the way we have always done it. The energy services interface is the gateway to a microgrid.

Microgrids contain collections of systems that may not share common technology. Some of these systems are small, self contained, and serve special purposes, such as appliances. Some are large and complex and span significant space, such as HVAC or an industrial line. Some look alike, are built from the same components, but have different missions; the laboratory fume hood and the air conditioning system are run for different purposes and have different constraints. Some may rely on different energy markets to do the same work; heat may come from electricity, gas, or solar thermal in the same building. Some systems may store generate energy used by other systems. All of these coexist in the ecosystem of the microgrid.

Diversity is the source of resilience in the economy and ecosystem. Monocultures fail badly in either. The diversity of systems in a microgrid is a source of stability. This is as true of the microgrid spans a campus or spans a high-rise. One source of diversity is diversity of response, which is tied to diversity of business service provided. A unitary system all too often has too few response options. Without expensive and non-standard integration, these simple systems are unable to expose nuanced and diverse services for manipulation by the humans, and human processes, they serve.

Diversity within kind (read Darwin for a definition) in building systems can come from multiple technologies (hard to maintain), or from multiple systems programmed quite differently (expensive to integrate) or from identical systems responding to different users. Diverse systems can be much more agile, just as individuals can be more agile than a committee. I posit that a collection agile systems is better able to respond to heterogeneity of environment, including unpredictability of power supply, than is a single committee of systems.

Diversity of services can provide new assets to the commercial building owner. Green leases seek to tie technology, capital, and performance together to please the tenant. Green leases require separate metering and operations for each tenant to be credible. Green leases in a high rise might work best with a number of identical systems, one for each tenant, rather than a monolithic system that responds only to all. Diversity is an amenity that enhances tenant service and leas ability.

How do we distinguish a microgrid from a grid? The external interface should be the same. Inside, microgrids are more intimate, they are the safe neighborhood the kids can go out and play in. Alternately, they may be more dangerous, the prison society in which no inmate must reveal anything. A microgrid defines a security context and a security posture. Intimacy and sharing and collaboration are all a part of some contexts—and not of others.

To me, the most interesting question of the week is what information do the systems within a microgrid need to share as they support their divers purposes and work within their mutual constraints. I know it starts energy usage, and predictions of energy usage, because that is the common resource they share within their environment, the basis of their economy and their ecosystem. I suspect they need currency, to negotiate their access to resources within the constraints of the microgrid—although I am not sure that currency is always expressed in legal tender. Some systems may only be able to buy at certain stores, or sell to certain buyers.

I’m not sure what else they share.

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.