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.

An Evolutionary Composite Services Framework for Energy

Future energy systems must not only support interoperability on operational, e-commerce, and security levels, but they must do so against a background of innovation. New technologies will arrive from innovators who are not traditional energy participants; it must be easy for these innovators to introduce their products and easy to integrate these products into the intelligent grid.

New business models, especially support for distributed generation and the hybrid technologies such as the zero net energy building, will demand new interfaces. These business models require symmetry, with each participant both a buyer and a seller of energy. Cost effective local energy storage will create new interaction patterns that we cannot know until we create the incentives that encourage market adoption. One thing is certain, the interface between the intelligent grid and buildings and industry will be different tomorrow, than it is today, and different still in another year.

Electric cars will have a significant position in our society far before we have worked out the market mechanics. The market mechanisms will extend beyond the simplistic “all cars will charge only in the middle of the night” to support on-demand rapid charging and selling stored energy back to the local home, business, or utility. The final market must support social scenarios such as holiday travel and new businesses such as the renewable energy parking deck. Again, we will face rapidly evolving interfaces for the near future.

We can most easily meet these challenges by creating a composite framework that supports diversity. These services will support the different types of business interactions surrounding the intelligent grid. These include but are not limited to:

• E-Commerce services to define the two-way buying and selling of power
• Capability and Capacity services to negotiate how much power is available at what quality irrespective of the underlying technology.
• Weather and similar services provide situation awareness to buildings and grid operators. Weather is critical to predicting energy consumption as well as to predicting renewable energy generation capacity. Situation is awareness is just as important to building and industry participants in new energy as it is to central generation and transmission facilities.
• Tariff and Regulatory interfaces, whether for long transmission, or for carbon negotiations, will guide energy markets beyond mere electrons.
• Security Services to control operations and protect privacy.
• Safety Services to provide situation awareness to linesman responding in emergency and other scenarios.
• Operations Services, supporting either third party operation of site-based generation capacity, or site-generation as a forward deployed utility asset.

Each of these seven interfaces will evolve over time. A user of one service may care little about another. As services become the basis for system-to-system interactions, keeping each service separate simplifies interaction patterns so each can evolve rapidly.

Rapid evolution and deployment are critical to new energy plans, particularly if we are to meet ambitious goals for more renewable energy, more distributed generation, and more electric cars. E-commerce and Security services can be based upon existing IT standards. Operational Services, where appropriate, can be based upon existing standards for substation operations. Weather services can be developed in different venues through the work, perhaps, of NOAA (the National Oceanic and Atmospheric Administration). Composite services will speed the development and deployment of the smart grid.

Composite services will also disconnect the different business processes from changes in other areas. Each business process is concerned with only a single service on its partners. As that service definition evolves over time, newer system will need to interoperate with version-based diversity within domain, rather than in all domains.

Energy systems are big infrastructure. Big infrastructure lasts for a long time and touches many things. Scale introduces diversity if installation. Innovation introduces diversity of interaction. Long life introduces diversity of versions. An Evolutionary Composite Services Framework provides the best platform for providing function and performance despite these three sources of diversity.

Distributed Generation and Lightweight Integration

Distributed generation is a big part of the anticipated new grid. Distributed generation refers to having many small sources of power on the grid. A traditional power company can own distributed generation or someone else, perhaps the building owner, can own it.

Wayne Longcore has described distributed generation today as akin to the early days of personal computing. The big centrally managed power plants have the role of the mainframe, the site where all real power generation occurs. Pocket generation plants, including solar generation on household roofs, are akin to the poorly networked early microcomputers, only able to get on-line with great difficulty, and unable to do much in the big grid. In fact, today, grid operators often cannot tell if some homes are selling power back to the grid. I guess this means that industrial sites with in-house cogeneration are the equivalent of the old minicomputers. Some readers might recall minicomputers and large workstations made up much of the early internet.

Wayne’s point was that users of the sluggish single-purpose computers of the day would have had trouble imagining the internet revolution of the 90’s. They would have had even more trouble imagining a conference like the one Wayne was speaking at, where most people carried several small computers, more powerful than the minicomputers of the day, ones able to play music and videos and surf the web at speeds unimaginable just a little while ago. After all personal computers were toys. Just like micro-generation today.

Pervasive communicating computers required the development of many small light-weight protocols. IP defined inter-computer communication. TCP defined how communications travel a wider network. DNS defined the way to find computers at a distance. Distributed generation will need many small protocols as well. The power of these protocols is that different brands of computers, or even quite different types of systems, can use them, making no distinction between mainframes, personal computers, or, now, even phones.

One protocol we need for distributed generation is a small lightweight pluripotent protocol for connecting small generation to the web. Today, grid operators expect to see a large and complex interface, specific to each type of generation, just as they do on their own substations. While new variants are derived from old, it can take as long to develop a new standard as it does the technology. The sheer number of these standards makes it difficult to integrate new generation points.

Zero Net Energy Buildings will have a mix of generation and storage systems. In most places, any building with storage is not allowed to sell energy back to the grid. Under today’s rules, a building with some solar power, a wind generator, and a diesel generator would need three separate interfaces to sell back to the grid. There is no defined interface for the myriad of low-voltage DC generating systems soon coming to market. These may not sell power to the grid, but may offset other internal needs, and thus influence power sold by “normal” generation. If each of these scenarios needs to be connected to the grid using current approaches, we will not connect many of them.

We need a common lightweight protocol to support agile integration of these new point sources of power to let distributed generation develop. There are some facts that grid operations needs to know about each substation, and it needs to know them about generating buildings as well. The grid needs this information not only for safety, but also for interoperability. But it does not need to know everything about the underlying technology, technology which may change over time. It certainly does not need the information to operate the underlying technology.

I will write about what I see as the requirements of this interface soon.

BIM, Services, and Emergency Response

The Building Information Model (BIM) comprises a family of standards, including the three dimensional building model, that compose a comprehensive description of a building. It is an oft hoped desire that the BIM, perhaps working through a mythical BIM server, be accessible to improve situational awareness by emergency first responders

One barrier for this BIM/Emergency management information exchanges is that BIM does not, by and large, define real service mapping. Chemicals and supplies may stored by room number. Ventilation may be by zones established long before the room numbering. Missing people may be in their office as per the directory, or in the conference room, which may not be identified in the BIM, elsewhere.

BIM could rather easily bridge the control system, with its focus on AHU3 by placing AHU3 in the building. If, say a return air temperature sensor is associated with both AHU3 and room 204, then one can imagine standard techniques to visually map rooms, and high heat through the control system.

The biggest issue is control systems tend to present their points for the building engineer, and perhaps one who has an extensive set of blueprints on hand to study. Furthermore, the contractor tends to limit the points displayed in any user interface to ones he is willing to defend. In an example on the UNC campus, we had a decades old building that we had replaced a chilled water valve on repeatedly because it was “frozen open”. When we established direct reading of the underlying control points, we found that a sensor that had never functioned was consistently claiming thousand degree temperatures. The contractor had simply excluded it from the user interface. (The valve is no longer “freezing”.) I wonder what would happen in an emergency scenario, if a point with this sort of reading were suddenly revealed through the emergency BIM.

Managing the diversity of energy generation, storage, and conversion systems in the Zero Energy Building will require interoperable service integration of the underlying systems. My thinking is guided by the service and reliability information of The Green Grid.

/articles/2008/9/25/divvying-up-grid-interoperability.html

These same abstractions would be very useful to the first responder needing to make quick decisions.. Is the primary power still operational? How much ventilation capability remains on the third floor? Is there additional cooling available? How reliable it the substation feeding the building right now?

Recognizing the operational status of these systems will be critical for responder safety in the years ahead. When a building includes on-site generators, electrical storage, and solar panels, it may be hard to simply cut the power to the building. The thermal storage well may be a supply of water to extinguish flames. The potential energy mass storage system (water tank on the top story) might be a source of power, dangerous or useful, a source of incendiary fluids or even mass. The vanadium battery in the basement might be a critical environmental hazard during building collapse.

If we move beyond single building to neighborhood disasters, these Green Grid derived services have new potential benefits. One scenario describes buildings sharing additional information during the period immediately after receiving a CAP alert. A common question might be whether the high school gym is in good enough shape to be a post storm shelter, or field hospital, or… Green-grid style informational standards would clearly improve this assessment. How much operational is cooling (or heating) and how much more is available? How reliable is the power supply? How long will the stored energy in the building last at the current burn rate? Perhaps even how long will the hot water last in the slow recovery hot water tank?