Interfaces for the Power Grid

This week has been crazy busy, but I managed to submit the following to the B2G interoperability group at NIST

Each interface around each process of the grid should allow bi-directional buying and selling. The interface should support discoverable diversity, allowing the standard to grow over time. Ideally, the interface would be the same for different forms of energy, allowing the same economic interface to be used for buying standard power from the grid, solar energy from the neighbor, or thermal energy from the data center in the basement. I should be able to set my heat pump with gas pack to switch not only on peak efficiency, but on the price for each fuel.

The interfaces should be non-hierarchical and composite. Remote power generation, the local sub-station, and the campus micro-grid should have full peer interfaces; my decision to buy from a remote plant or a local storage facility should be through the same interface.

So, what are the characteristics of this interface?

E-Business Interfaces
Offer and Acceptance

Price is clearly the first component; price is how we indicate value and scarcity. Short of a surprise malfunction, every brown-out is a failure of pricing. As pricing may occur in the context of an auction or negotiation, prices must go two ways, as an offer, as a bid, as a request for quotation.

Price Scenarios

Note: in the scenarios, day (or tomorrow) can be replaced by week, month, year or any other period one wants to contract

• Your current power costs is this much
• Power costs this much tomorrow.
• The price curve for tomorrow is…
• The price for up to so much power (perhaps as a per cent of yesterday) is x, for over that amount y, for an arbitrary number of levels,
• One-time urgent offer with no bid.
• One-time offer to be bid until market clears
• Demand Response is either a new auction or it is a RFQ for power buy-back already negotiated.

Transaction Scenarios

• Your instantaneous use is…
• I want to purchase this amount of energy tomorrow.
• If the price curve for tomorrow looks like this, my purchase will look like…
• We accept your offer as above and wish to enforce it.
• Short term request to relinquish previously agreed to power.
• Short term request for additional power bids
• Long term request for significant give-back, say a summer furlough
• Failure to perform will result in power costs of…
• Other Transaction Details
• Penalty for underperformance [as producer] is…
• Penalty for underperformance [as consumer] is…
• Contract is enforceable, and consumer use will be throttled to meet agreement.
• Contract was authorized by …
• The following power qualities are critical to this contract….
• This security token / ID / account overrides normal billing process (especially for electric cars)
• Qualities of Power Delivered

Other qualities of power must be transmitted along with price. In some circumstances, these other characteristics might trump all other considerations, as projected reliability might concern a data center as much as price. It may be a condition of contract that the supplier notify the buyer of changes (or predicted changes) in a “critical quality” (see Other Transaction Details) as quickly as they would of a DR or other rapid response scenario.

More may be discovered in the future, but an initial list might include:

Quality of Power

• Predicted Reliability of Power during time of contract (perhaps derived from EERP).
• Additional capacity in critical bottlenecks. This attribute may be a quality of a substation, or it may, stripped of price and transaction, be a quality of an internal UPS or electrical panel.
• Remaining power at current or predicted burn rate. This may describe diesel generator, or fuel cell, or …
• Remaining Time / capacity to fully recharge storage.
• AC or DC
• Carbon accounting of supply
• Environmental accounting (wildlife, habitat, renewable, etc) of supply
• Geo-location of supply (allowing Buy Local and NIMBY to each affect markets with their dollars)

Should power stored in a battery report its effectively higher carbon load when it is sold or consumed?

Other Market Issues

All interfaces should support many-to-many interactions. A customer should be able to select from any of several aggregators if available. A customer should be able to buy from specific generators beyond the local T&D if desired. There must be a way for the buyer to discover power sources that meet the characteristics he desires and to negotiate with them. There may be times when local transmission conditions want to find emergency load use rather than emergency shedding.

Market Fables

These are use cases, but they have been selected to push away from traditional scenarios. Traditional use cases have already been well handles by others. What follows are edge cases, designed to test the limits. If we do our work well, what Fred Krupp calls the “winners of the race to re-invent energy” will be able to innovate in ways I cannot anticipate.

The Electric Car

In the evening, the electric cars come home, drained from a day of driving. Perhaps they were doubly drained, used to carry their office buildings during the afternoon brown-out. What will people want from their cars next….

• To sit in the garage overnight, slowly charging.
• To be ready to drive 15 miles in twenty minutes when I go get one last kid from athletic practice.
• To be at least half charged and ready for anything in two hours when the baby sitter arrives and mom and dad head out for an evening on the town.
• To quickly get to at least a 40 mile range in case I get an emergency call from the nursing home, and thereafter just be sure to be ready for the morning commute.
• To get a charge for 15 miles by 8:15 when I head to choir practice at church. Better make that 25 lest we stop for coffee afterward.
• It's two hundred miles to the beach and we plan to take full advantage of the expensive week-long rental by getting there tonight! Kids, grab your bags, we are leaving in 20 minutes. Oh, and the car needs a full quick-charge, no matter the expense.

The above require a wealth of power signals. Some of them (capacity of current storage) can be transmitted back using the same interfaces as we have for capacity of a house battery. Not all interactions will be with the home base of the car.

When parking downtown, I want to plug in my car. I may want to choose between a quick visit, for a cup of coffee, and an all-day back-to-school shopping event.

The Green Garage™ offers locally generated wind power for re-charging at its own special rates that vary with the wind. Having been burned once, I want to check prices before I leave the car.

When I go over to your house for dinner, I want to plug in. Being a polite guest, I of course want the charges to go onto my own bill.

The whole family gathers in the next town for Thanksgiving dinner. All cars are drained, and need to recharge over the next five hours except for the college kid, who arrives at the last moment, and leaves as soon as he can. Grandpa decides to overrule all normal agreements and cover all the charges for cars plugged in at his house.

The Transacted Household

Zero Net Energy Buildings will be built around local energy generation, storage, conversion, and recycling. These diverse systems will be too complex to manage as control systems, and will have to be interact as agents exposing services. In this model, we will leave them to negotiate power usage among themselves. These devices should use the same economic interfaces rather than detailed control interfaces.

I could ask my dishwasher to run itself, and manage its own budget for the month. I could also set service standards that the dishes always be clean before dinner the next day. This leads to a relatively simple and consistent user interface.

I could tell my solar panel to sell to the grid whenever the price is above a certain amount, and to store any excess energy. The grid might consistently outbid the dishwasher—and that’s OK. If so, the dishwasher would still run only at night.

I could tell my whole-house storage system to buy power at any price until it has four hours on hand. Thereafter it might buy whenever energy is below a target price. I could even let it take bids from the household systems and devices, or from the neighbor. This system would need to charge an appropriate mark-up based upon its inefficiency of storage.

The right sort of abstract business interface between the power grid and our buildings can also be used between buildings, or within buildings.

Third Parties

There must be ways to delegate authority and rights cleanly between parties. Intelligent buildings will move toward knowledge-based maintenance based upon building system analytics. This service will be supplied by remote specialists. These specialists will need access to live use rates and pricing to supply business-ready information (Change the filters on the 3^rd floor; at your energy prices, it will costs you $146 per month until you do). Today, it is difficult to assign rights to such “privacy” sensitive information.

Conclusion

My chief concern is that we do not over-integrate and thereby stifle future innovation. The Grid’s interfaces needs to be lightweight, composable, extensible, and able easily to interoperate with the service, security, and e-commerce standards of business and the internet.

It’s not Use Cases, it’s Interaction Patterns

The NIST B2G efforts so far have annoyed me like an itch I cannot quite scratch. The B2G (Building to Grid) group is trying to collect applications and use cases, to create the desiderata for the new interface standards. These are the traditional ways to characterize known systems. Certainly even distinguishing the two can be a strain, although practitioners may prefer one over the other. And yet there is that annoying itch…

This morning over coffee I realized that it is because we should be talking service instead of procedure.

One of the truisms of Service Oriented Architecture (SOA), is that it is nearly impossible to implement a SOA in a Procedure Oriented Enterprise (POE). (POA is the "antonym" of SOA, only discovered after SOA existed, in a manner similar to the term Analog Watch only being discovered once we had digital watches). It is easy, relatively, to implement SOA in an organization in which each department and each departmental system knows what its purpose is, and what its effective business metrics are. Such a well understood business can be referred to as the SOE.

A standard SOA talking point is the virtual company assembled entirely from the Services provided by others. Virtual companies are almost inherently SOEs. Many of the new markets I can imagine seem more like virtual companies than they do like the process-oriented companies that make up today’s energy markets. We should be thinking service.

We need to focus on interaction patterns, the approach at the heart of service integration in the e-commerce side of web 2.0. To enable the new markets that most of us hope can arise from these efforts, we need to shift from thinking in terms of request-response and buyer-seller-shipper interaction scenarios. The patterns we must document here go beyond simple bilateral interactions, to include multilateral, competing, atomic, causally related, and routed interactions, and should allow for any number of long-running business processes.

The new smart grid, and the new economies of Zero Net Energy Buildings (ZNE) will involve the discovery of and interaction with services. These service will be involved in energy generation, storage, and conversion. These services will be diverse and multi-party. These interactions will not be procedural.

Now that I have my head on straight, I hope to submit interaction patterns required for new energy markets soon. But I thought I would give everyone a heads up on what I think is the real task.

Business Exchanges on the Grid

Notes on SmartGrid Domain Experts Workgroup, NIST, August 5, 2008
NIST (National Institute for Standards and Technology) started by making a strong claim for ownership in this area, citing Title XIII, 1305 of EISA 2007. NIST set out an aggressive agenda including a preliminary report at GridWeek on 9/24 and a NIST workshop on developing standards at Grid Interop in Atlanta November 11-13.

NIST wants to have in place tight working relationships with the target SDO’s (Standards Development Organizations) in place before 2009. NIST and the GridWise Architectural Council are working together to direct the standards direction toward e-commerce and interactions with building operations and with the building occupants. Some of these standards will be e-commerce focused, some will be looking to the Building Information Models, and to the energy models they support. I am excited that this might push these design approaches into continuing use during operations.

B2G Breakout (Building to Grid)

We quickly agreed that goal of the SmartGrid standardization efforts is to design the information exchange and informational interoperability to enable healthy markets to emerge around energy use in buildings. Success was defined as enabling buildings to trade their energy.

The group was in violent agreement that we needed to work on business to business interactions, and not on machine to machine interactions. Services inside the building would be coordinated by the business processes of the occupants. Grid messages would go to the business agent of the occupants. Interactions, including pricing and bidding, would be between the grid agents and the building agents.

But market development for what? The problems that need solving quickly include real time pricing and automated demand response. The solutions should encourage the development of distributed generation and local energy storage. The Pricing Models and Buying Models for Energy should also work inside microgrids such as the building or neighborhood.

We spent a considerable time defining the characteristics of live pricing. There was intense interest in moving beyond static prices to curves, i.e., if the prices move like this tomorrow, I will commit to energy consumption in a curve that looks like that. Automated contract execution and on-line exchange of tariffs are both desired.

One thing that everyone agreed is that automated metering infrastructure would never meet its potential unless full live real-time access to all meter information is made available from *both* sides of the meter should be the standard. Parties could then collect the data in accord with the schedule that made sense to them.

This has been about the business exchange – soon I will write about the attributes of these transactions and product differentiation on the grid.

Service enabling Telecommunications – lessons for Buildings and Grid

Peter Carbone, Vice President of SOA for Nortel, gave a nice high level talk at the OASIS conference on the challenges facing a company learning to dance in the world of SOA and mash-ups. Nortel, of course, grew up with rigid account control and vertical integration in a regulated environment. As markets for building systems are still characterized by rigid account control and vertical integration, and the power grid is still vertically integrated, regulated, and almost complete account control, there are some useful lessons.

Infrastructure convergence was the enabling and driving change for telecommunications. Provisioning telecommunications was long the most difficult task. Over the last decade, the diverse communication infrastructure converged to a single packet-based infrastructure with resulting dramatic simplification of security and reliability. The questions move from “What low level communications do you need” to “What interactive services do you need?”

This evolution changed how Nortel had to think about and market their services. Before the change, Nortel sold vertically integrated applications that were inflexible. As the core technologies converged, Nortel was forced to decompose advanced services into core functions and then plug them back into the new architecture.

Fortunately, decomposing integrated services into core functions looks a lot like defining a service for service oriented architecture. Fundamental telecommunications functions can now be built into enterprise applications without requiring exotic skills are deep domain knowledge.

Skills-based routing and deployment was one example. Peter discussed a SAP integration with critical system causing expensive downtime, emergency part ordering, and synchronizing communication with an outside expert so that the repair personnel, the piece of equipment, and, via telecommunications and real-time identification of the expert on call, the expert’s telepresence were synchronized.

In a similar vein, he discussed abstracting the GPS function from the cell phone to block access in the security system when the phone was in a forbidden zone. Peter gave many more examples and you can find his slides on the OASIS conference site.

So what can building systems and the power grid learn from this?

Well, the owners expect the systems to just run, and are annoyed when they are expected to learn terms like BACnet or LON (or any other control protocol). We need to decompose advanced services to discover the core functions, from the owner’s and the tenant’s perspective, and present them as interfaces that can be plugged back into the enterprise.

As Peter summed up the C-Level response: “I just spent $100 Million fixing my processes, you had better be compatible.”

Building services that can present themselves as that can interact with SAP, or with PeopleSoft will have an advantage. The services that know how to display themselves on Google Earth will know how to request the nearest technician.

Likewise, Grid requests that present themselves to ERP services will find faster acceptance. Grid requests that describe grid pricing as shapes that can be pinned to Google Earth will enable the enterprise to come up with multi-site responses that may be different from any single site.

No one cares about the old vertical applications. Enterprise interactions are everything.

This is why the Building Service Performance Group at ONTOLOG (just goggle it) is meeting tomorrow.