Idle Thoughts on Smart Grids

Musings from the GridWise Architectural Council, Orlando, 2010

After a week at the AHR show, and meeting with ASHRAE, and sitting in on B2G (Building to Grid) summit, I was back in the building zone as I sat in on day one of the GWAC meeting. The GridWise Architectural Council (GWAC) is a voluntary organization of people concerned with the future of energy. The Department of Energy sponsors meetings of the GWAC, a commitment that keeps the group in meeting rooms, coffee, and pastry. The DOE also provides administrative support through Pacific Northwest National Labs (PNL).

The GWAC is immensely influential in the development of the North American approach to smart grids. It draws members from many industries and not just the best thinkers of the utility industry (although its members include those, too). The GWAC often meets at the end of conference or show tied to a different field of energy, to cross-pollinate their approaches. This week, they met after the AHR show. I have never had the time and resources to commit to a GWAC membership; the members make a serious commitment of time. When one of their open meetings is in the same town as me, I always attend if I can.

What follows are mental doodles from my meeting notes, none long enough to warrant their own post.

Is Demand Response the worst marketing phrase ever?

Demand Response is the girlfriend (or boyfriend) who you dated for a while, but dumped because she only talked about her problems. If utilities want to people to care about DR, they have to come up with some better way to talk about it. Until they do, energy suppliers are going to continue to have a hard time engaging their customers.

Is Customer engagement “the disruptive technology”?

The system designs of electrical grids have been defined by deep integration and process interactions. Service integration and service orientation were unknown. The services, both between supplier and consumer, were undefined. Even within the consumer realm, the services were not defined. Rarely does a commercial owner hope to buy electricity on any given day—electricity is not a service. . . Lights, warmth, computing, music, even flushing toilets, now, those are services.

What will it take commercial building owners to embrace energy response

A building owners business is to operate a building efficiently without, at a minimum, annoying his tenants. If he knew a way to use a third less energy without annoying them, he would be doing it already. Annoyed tenants may not renew their leases. It is safer to avoid this risk.

If a building owner could see how each part of his building would respond to DR, and knew which tenants would be annoyed, this risk is removed. I think the killer app of demand response can apply all service degradation only to those tenants who are habitually late on their rent.

Why does the smart grid have no formal architecture?

This was a real challenge when developing the national roadmap. We did not want an architecture, for a good architecture is ultimately an expression of a particular business model. When we developed the national roadmap, we wanted to support any number of business models, both those known today, and those we might find in the future. How would a traditional “architecture”, or perhaps even a TOGAF-style instantiation of Intelligrid, handle, say Google becoming its own virtual utility buying directly in multiple ISOs? We deliberately left architectures undefined.

We had to socialize the services as “reducing the size of interoperation domains” to enable innovation by reducing the requirements to form cross-domain interactions

Why does it seem that there is a fundamental contradiction between the smart grid and new technology?

When integration and interoperation are the biggest challenge, then diversity is the biggest controllable expense, and technical innovation is the biggest controllable risk; it is most easily controlled by preventing the introduction of either. The smart grid must introduce both.

The real question, if properly constructed, is not how we create The Smart Grid™, but how do we define Service Oriented Energy (SOE), of which the Service Oriented Grid is just one arranged subset. The SOG interacts with another entity, with quite different purposes, the Service Oriented Building, The SOB exposes some of its attributes and behaviors through SOE interfaces.

From this, we derived the existence of an Energy Services Interface (ESI). The ESI is the external face of any building or microgrid. What happens behind the ESI is of no concern to the grid other than how it effects how the node behind the ESI comes to market.

Can you really keep your mind on smart grid all the time?

No. During most of an excellent talk on new energy generation from FPL, I was thinking, “It won’t be carbon that destroys the biosphere, but alternative energy, specifically, through the slowing of the Gulf Stream by ocean current generation and slowing of the trade-winds by wind turbines…”

Smart Cars at Home on the Smart Grid

Too many of the scenarios for electric cars on the smart grid talk only about the relationship between the single car in the home and the grid. These relationships are not the most important ones, and will not determine the successful integration of millions of electric vehicles into the grid. The relationships that matter are those between the cars and their drivers, their family plans, and the other cars in the household. Car software will be even more important than car performance.

The successful car software will begin learning about its owner from day one. It will learn the schedule of its driver, and how far he drives each day, and when. I say learn, because the successful car will pick up this information without requiring programming. This will mean that programming will normally be by exception.

Over time, the car will learn how often these standards are broken. If periodically during the week, the family drives over to Grandma’s house, four miles away, then the car must have reserves for an nine mile drive. If that drive is the only trip during the week that piles the entire family into the car, then those nine miles must be for a more heavily loaded car. Each bit of this learning can affect how and when the car buys electricity.

A challenge in any household is managing the family schedule. Soccer games and little league responsibilities may be spread over the house. A car may leave home to park at the airport for a week. The whole family and all its cars may plan to drive across town to grandmother’s house on Thanksgiving. Just as the family must coordinate their schedules so no one is left behind, so the cars must coordinate their charging schedules, so each car is charged up when needed, and the electricity was purchased at the lowest cost to the consumer.

There are different ways to coordinate the cars. The family may manage a common calendar, perhaps on a flat screen mounted on the refrigerator door. The common family calendar may interact with family PDAs and cell phones. The family cars may get their target schedules from this common calendar. Alternately, the cars may be able to “see” each other, perhaps using Blue Tooth. Somehow the cars must negotiate priorities. Does Mom or Dad get top priority for charging? Does the college kid who works at night get top priority in the late afternoon? If grid power is expensive, can that college kid buy power from another car? Will the relative efficiency of each car’s battery be factored into those decisions?

So far, we have not moved beyond the garage—except to the refrigerator schedule.

In the well functioning household, all the parts need to work together. Thanksgiving day laundry with an electric dryer may anticipate that Thanksgiving day trip. Hair dryers can be anticipated in the hour before departure. In-house generated power may be part of the decision process. Weather reports may help predict the amount of in-house power that will be generated as well as what the external power prices may be.

The interfaces that make this work are not engineering interfaces. They are human interfaces. The interfaces that make this work are cross-cutting interfaces. They will not be managed by end to end controls.

The team that does this well will have the killer app for cars...

The Smart Grid is Not Faster RTUs

There is a growing awareness of cybersecurity for SCADA systems, one that has not, as of yet, brought anything like real security to SCADA in the power grid. SCADA (System Control And Data Acquisition) refers to the processes used for central control and operation of our biggest process systems. Process systems in this case include the distribution systems used for the electric grid and for water distribution systems: large not-very intelligent systems. I say not very intelligent because the often use a model in which each node is dumb as a thumb tack, and nearly as secure.

New business processes are demanding entrance. The utilities need DR (Demand-Response) to deal with their most pressing needs, but do not wish (for the most part) to share live metering data (“we think you should be happy with 15 minute intervals.”). We have a system architected so badly that “RTU interoperability” is considered some sort of holy grail. Perhaps this would be legitimate if RTU communications were some sort of high-performance wonder, but they are not.

New business models will break the old design philosophies. Distributed generation will mean that the substation operations you are monitoring will be controlled by someone else. Perhaps that someone else will include everyone with a zero net energy building. Perhaps that substation will be run by the Green HOA (Home Owners Association) set up by the large commodity builder complete with its own neighborhood generation.

This means you will have to assume that the substation is owned by someone else. This means that if you do have “one RTU incompatibility might take down the system” problems, then your system will be down. Failure to acknowledge this is just whistling past the graveyard.

The current power engineers run hierarchical end-to-end control systems than anyone. The question is, will this be like being one of the folks who understands SNA best, claiming to the end that only structured hierarchical controls can keep things afloat, while folks like NERC acknowledge greater instability every week.

Things will change. That change will involve embracing multi-party communications at the substation and at the end node. Thos multi-party communications will require something better than sealed end-to-end channels.

This is the way the tides are going. The choice is to promote the desirability of holding back the tide, or to acknowledge the rising damp.

Federated security. Multi-party communications. New market models.

Embrace them or become obsolete. The smart grid is more than just upping the speed of communications with your RTU.

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.