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!

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.

Smart Grid Blood on the Floor in DC (1 of 3)

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

Thirty ornery smart grid partisans gathered outside DC last week for a hastily convened review of the customer oriented standards development plans. To one side, the plans developed at the August Standards Development Organization (SDO) was putting critical ongoing deployments of billions of dollars infrastructure upgrades at risk, and throwing long term plans into disarray (Team A). The other side saw keeping the August plans intact necessary to enable new investment and new participation in distributed energy, and to break the iron grip of dinosaur twentieth century processes and organizations that impede new energy (Team B). There was little common ground.

The NIST smart grid process identified a number of Priority Action Plans (PAPs). Four of these defined the border between energy supplier and buyer in the smart grid. These communications occur between utility and end node, whether that node is house, or commercial building or industry. These standards are for Price and Product communication (PAP03), Calendar and Schedule communication (PAP04), Energy Usage information (PAP10), and communications for Demand Response and Distributed Energy Resources (PAP09).

The first morning passed with quiet platitudes, until Dr. David Wolman, technical lead for NIST on its smart grid project, called for "blood on the floor" during the afternoon session. The participants complied with enthusiasm, and the conversations became more interesting and more revealing.

Power system engineering standards are developed in the IEC TC 57, the overarching technical committee (TC) defining standards for power management. TC 57 has defined a common information model (CIM); and utilities are striving to rationalize their world by using only elements defined in “The CIM.” Some of the suspicion with which building systems technologists regard the CIM is due to a historic tendency to fit all building operations into the TC 57 CIM

Representatives from the end nodes, particularly commercial buildings and the business enterprise, do not see their world as an extension of the power grid. These areas have their own information models and find the phrase “The CIM” mysterious and unhelpful. Financial services use a CIM defined by ISO 20022. Building systems have information models defined within the divers building control system communities. Enterprise operations beginning to define their interactions using information models from defined by EBXML (electronic business XML) or UBL (Universal Business Language).

The first key agreement of the two days of meetings was to respect the multiple information models on these inter-domain interfaces. For elements and communications that are purely power management related, everyone agreed to use to use the TC 57 CIM. When the communication element involved business transactions, or schedules, or some other area, the communication would use the informational models from that domain.

A common understanding on semantic models, including when to use such models from outside the domain of power management, was important to bringing the divers interests together.