What is an internet of energy?

In the political world, we often speak as if the smart grid will create and internet of energy. This sounds sexy, but it can be hard to noodle out what it means. I’m pretty sure that it does not mean that we will use smart meters to deliver porn. To find the internet of energy, we must acknowledge straight up the problems with our energy plans.

The internet was built around assumptions, scarcity of bandwidth and fragility of infrastructure, that clearly apply to today’s grid. Long distance transmission was expensive; email used to hop across the country on late-night phone connections to the next state. Every engineering decision was based on occasional connections, local management, and the knowledge that it was risky to rely on anything that was not controlled in-house.

Because we knew so little about what would happen next, we solved little problems. We did not make assumptions about how the next segment would handle our messages, or how reliable they would be. This allowed constant technological churn. Once we had TCP, IP began to drive out local protocols such as IPX and NetBIOS, and quickly supplanted top-down engineered protocols such as GOSIP and SNA.

On the infrastructure side, the churn was just as fast. I remember when X.25 was the future, and supported the first North American installation to supplement the banks of modems at CityNet. I remember when we signed up the Boston Choral Society, and gained users with perfect pitch, who bedeviled tech support by describing modem squawks by note. For ears, I telecommuted via dual ISDN lines back-fed out of Siler City, but tariffed as local connections. Each change of infrastructure was a minor blip for home and office communications.

Even the applications changed, always moving toward the simpler and less architected. Single purpose bulletin boards were replaced by Gopher servers and WAIS. Walled gardens such as AOL and Compuserve began to open up to the wider choices of today’s internet. Waves of push technologies failed and peer-to-peer regularly raised its transgressive disruptive hand against the top-down passive order.

Somehow, by planning for infinite scarcity, in every cell of networking, and in every switch and gateway, we found ourselves with unimaginable surplus, in which computers in our pockets are now network connected with greater bandwidth than used to connect supercomputing centers.

The key decisions of the smart energy are to reduce operating margins, to not build enough transmission and distribution, and to use intermittent power sources such as wind, sun, and tides. We are planning for the grid to provide lower quality service than it has in a hundred years. We have now forced ourselves into the corner in which network communications found themselves in the 70’s. We can only gain the same success by committing to the same principles.

The future of the grid will be based upon intermittently available energy distributed over inadequate and expensive wires. It will be too expensive, both in energy losses and in capacity management, to get our power from far away. We will have to make our energy decisions assuming occasional connections, local management of use, and the certain knowledge that it is risky to rely on anything that we do not manage in-house.

For a while, we will try to solve these problems with central decision-making and a hierarchical organization. Utility-based management of home and business use will make sense to traditional power engineers, just as SNA was briefly the networking strategy natural for mainframe users. This will fail under its own internal contradictions. The DOE envisions homes and businesses able regularly to operate off-grid for a week; it is unlikely that such remote energy management will work when the grid is down.

Each time we plan for unreliability, we can gain another level of reliability, accept another level of innovation. Homes that are indifferent to grid reliability can accept the local installation of self-contained, self maintain pocket power plants. Pocket power plants may be subject to longer outages through poor management, but their customers won’t care. Novel strategies of congestion pricing and load management may provide inconstant power to the neighborhood distribution, but the neighborhood will be relatively insensitive.

At each level, planning for scarcity and unpredictability will add resilience. Resilient systems will be better able to accept diversity; acceptance of diversity is a requirement for allowing innovation. As system that accepts innovation, in ways today’s static grid never will, will accept the creative destruction, the quick success or failure that draws venture capital and engineering ideas together.

The future quality of the grid is lousy; that’s the plan. Embrace its failures and unreliability, because that’s where markets will follow. That is how we will find an internet of energy.

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!

Monday Morning at the Smart Grid SDO Workshop

Seven pre-meetings and a plenary into this workshop, it already feels like I have been here for a week. It has come a long way; everyone from the president’s Office of Science and Technology Policy (OSTP) to the state-side National Association or Regulatory and Utility Commissioners (NARUC) is on the same message. Smart grid interoperability standards must provide a platform for innovation. We must support more players and new entrants into energy markets. We must not make decisions in one domain that constrain the other domains.

Even before the conference started, I was talking to new people bringing their skills and knowledge to the problems of energy. Last night, I spoke for a long time with Greg Schwartz of CalConnect on the problems of coordinating activities across our daily lives, whether class schedules or energy prices, whether building systems or industrial operations. He identified his biggest problem as one of institutional awareness. CalConnect has key technical members in Oracle, Microsoft and Apple. Increased awareness is needed so that their calendar standards people will be given the time to finish the cross-cutting web services of scheduling.

The FIX Protocol consortium is here in force. FIX, a standard for financial information, provides the underpinning for the world’s major trading operations, from stock exchanges to commodities. The support and cooperation of FIX can help us get to transactional energy much faster.

Even at breakfast, I was talking to someone from the ASE, the automotive standards group. While she is here (Carolyn? - I wish I was better with names) to discuss the issues associated with electric vehicles. As the conversation continued with themes of competitiveness and knowledge drain, we turned to integration strategies. Cars have been under incredible cost and integration pressure, and have used service oriented integration of control systems to improve integration while reducing complexity. Detroit may be the place to hire engineers experienced in service oriented control integration.

George Arnold is emceeing the morning; anyone who has been following the smart grid process knows where he stands: informational interoperability, cooperation among the SDOs, and above all, speed of standards development.

Aneesh Chopra, the federal CTO described the goals of the administration and how they tied to this effort. He named key overall goals of enabling technical innovation, improving global competiveness, and open government. The meme he rode the longest was "verbs not nouns". Too often new systems and new standards are nouns. "Now we have a system". "Now we have a standard." He wants us to focus on effective use of standards. How many people can use each interface. What new uses or approaches to energy use these standards?

Now I may always here the same thing, but I heard "light, loose service oriented standards" in every bit of his talk.

Well that was the first half of the morning. More later.

Do we really need "IP Everywhere" in the smart grid?

If you want to start a fight in a crowd of smart grid participants, you can begin one by announcing unambiguously how you feel about IP (Internet Protocol) everywhere. Vendors fight to gain advantage for or to forefend elimination of their product lines. Utilities become passionate to defend their AMI projects and their rate bases.

Many of these conversations are premised on (to my mind) flawed thinking. Others need to define what they really want rather than relying on a simple slogan. I am a passionate believer in both open access to information and to open interfaces. I am also against IP everywhere.

One frequent claim is that I may need to talk to any device from anywhere in the future. I need no communication protocol for the car next to me on the free way to access my carburetion strategy. It is a security feature that the pierced guy next to me at the coffee shop does not have an IP address in the credit card in my wallet. Remote access reduces accountability. Remote access creates security requirements. Security requirements create expense and complexity.

We understand this everywhere but the grid and other aspects of the Internet of Things (IOT). When integrating engineered systems, there is a pervasive urge that everything must be able to address everything else at all times. Direct control of remote systems usually reduces quality of both experience and performance. As Gail Horst has explained succinctly, a clothes washing machine already is able to operate its internal controls; it knows that it can’t respond unless it is not full of bleach. It needs to expose only enough to indicate how and when it can respond, and to receive plaints of urgency and notifications of price.

For example, the Energy Management Service (EMS) manages the internal energy use in the home or commercial building. Ideally, an EMS needs communications of price, and of how much to shed, and to make a commitment. Period.

If the occupant chooses to outsource the operation of its EMS to an external third party, then the EMS needs additional capabilities to pass messages about internal devices and capabilities to that third party and to relay commands from that third party to the systems and agents within the building. If the third party happens to be a utility, and the utility business and regulatory model includes direct control by the utility, all messages should still be through the EMS. Today, third party management by the Utility just happens to be the default set of decisions in many parts of the country.

Nothing about this model mandates any shared IP space, or any direct addressability. I would argue that this model accurately describes the *business* model. So what are the IP wars about?

IP interfaces support easy interoperability within a domain—but interoperability between what. I do not need an IP address on my disk drive, although there are business cases when I may want it. The interoperability between things is needed for those loosely coupled situations that I may want to reconfigure/reassemble easily.

Building operators and building integrators are often frustrated by their inability to directly read meter data. The utility may have carefully engineered a solution to collect meter data at fifteen minute intervals to support billing. That solution may use non-standard protocols to wring every bit of performance through a limited communication channel. The billing system may use a batch process to post this collected data against each customer hours later. That information may only be available in a web page after carefully logging in.

The building system integrator would like to access live data for shorter intervals when tuning systems. The building operator would like to access this information in real time to support demand response. These functions require reading the meter on demand. The barrier is that meter data is collected only to support the billing system, and only to meet the needs of the billing system. The problem is sharing information only after processing. If IP were used to support the existing process, none of that would change.

In between domains, there is always a gateway. That gateway may be translating from CDMA to 1000BASEFL, it may be merely performing Network Address Translation (NAT), it may be doing semantic and ontological translation. It is still a gateway from one world to another. As such, either side should barely trust it. As such, it can have different protocols on either side.

The smart grid needs information sharing and informational interfaces. It needs discoverable interfaces at the domain transition, because I don’t care how hard the CPUs are processing, I’m concerned about the 3 days of head scratching, cursing human time needed to integrate each interface (which means every home, building, and factory) when someone switches to a new version of something somewhere.

The smart grid should leverage web developed and web-derived technologies, protocols, and interactions wherever in the smart grid they can speed development, increase transparency, and ease interoperability with adjacent domains to meet business goals. It does not need IP everywhere.