Thanks for all those comments on my earlier post. I have updated the work and am re-posting.
The smart grid is more than improved top down control; it is a grid ready for unreliable energy sources (such as wind, waves, and sun), distributed generation, and Net Zero Energy (NZE) buildings. NZE buildings sometimes buy energy, sometimes sell energy, and energy use balances out over the day, season, or year. The NZE building presents particular problems as it may switch from buying energy one minute, and selling energy the next. Plug-in electric vehicles, whether hybrid or not, present the challenges similar to those of NZE buildings, with the added complexity of mobility. The smart grid requires distributed decision making, distributed responsibility for reliability, and easy interoperability to integrate an ever-changing mix of technologies.
The smart grid will be transactional, with each decision to buy or sell power a separate transaction at a separate price. The price of these transactions will vary dynamically, as a live energy market determines the clearing price at each moment for each sale or purchase. The smart grid will be open and transparent, wherein consumers can choose what kind of power to buy, and providers can prove that they are selling the kind of power they promise.
Alex Levinson of Lockheed Martin has named the suite of standards we will need for the smart grid as Smart Grid Information Exchange (SGIX). What follows is a personal view of a dynamic roadmap of the standards that comprise SGIX.
- SG Pricing: Price is more than a number. If I ask you if prices are up or down at the store, the answer is not “7”. It is not “Tomatoes are $3.00.” The price is “$3.57 per pound for the organic vine-ripened greenhouse heritage Cherokee tomatoes.” Each buyer can choose which attributes affect their purchase decision. I may choose to buy the cheapest tomatoes. I may choose to buy only organic. I may grudgingly choose the most expensive because they are the only ones in the store. SG Pricing will flow throughout the system—a model known as Prices to Devices. Under prices to devices, each system within a home or building may make its own decisions based upon budget and priority. I will be able to choose to run the fountain in front of my office only when wind power is available and below a certain price. SG-Pricing will be part of the SG Energy Market Information Exchange TC.
- SG Metering: This is a simple standard of energy flows by time slice. It also includes direction, as power may flow one way for a time, and then the other in a distributed world. To achieve transparent clearing markets, SG-Metering report what amount of what kind of power was purchased at what price at what time. If my neighbor and I buy the same amount of power at the same time, we may pay different prices because we may have made different decisions on how to buy. I may owe to my utility or to my neighbor for that purchase of solar power. SG-Transaction is in effect the accounting journal entry for each purchase or sale of energy.
- SG Energy Market Information Exchange: There is some bidding and exchange of information in advance. In my mind, this looks somewhat like commodity markets for those who want to participate. It includes elements of weather arbitrage. It includes time and reliability. It includes all of the elements of price. SG-EMIE will be developed in the Energy Market Information Exchange TC.
- UnitsML: UnitsML offers an unambiguous way to describe all physical measurements, and an unambiguous ability for a computer to look up the translation of any units of measure to any other units. SG-Pricing, SG-Transaction, and Energy Market Information Exchange will use UnitsML. UnitsML is an existing OASIS committee which will need some assistance and wider participation to complete.
- WS-Calendar: We all use ICALENDAR (IETF RFC 2445, http://www.ietf.org/rfc/rfc2445.txt) to unambiguously exchange information about time intervals. You used it the last time you clicked on an email attachment and suddenly had a meeting on your personal calendar. We need the same functionality standardized for web services. We will use it as part of pricing, and weather predictions, building management, and other decisions. WS-Calendar will be developed outside the SG effort as its anticipated uses extend into many business interactions.
- Digital Weather Markup Language (DWML): DWML is an existing specification developed by NOAA. NOAA offers a web service to which one can submit a longitude and latitude and receive in reply a DWML forecast. Most forward forward-looking energy markets are based on assumptions about weather. Most historical analysis of energy use includes recalling the weather environment. The most successful energy middleman base their business on understanding microclimates. We need to define a DWML profile for reporting as well as forecasting, to enable the exchange of actual conditions as well as forecasts. Such a profile would be used when querying local weather stations and even personal weather systems. Such a standard should include UnitsML (for internationalization) as well as time (WS-Calendar). We should encourage NOAA to develop the DWML specification into a standard; DWML also is of interest to the Emergency Response community.
- WS-DD and WS-DP: Device discovery and device profiles have been used in computer networking for some time. Device Discovery lets you find all printers on the network. Device profiles let you decide which printer to use when you want color duplexing. These functions are being standardized for the web. Schneider, one of the largest conglomerates providing systems for the grid and building is looking at providing WS DD and WS DP for all the equipment it sells. I think it will have a big role in the future world of distributed generation and Net Zero Energy facilities.
- SG Energy Interoperability: I envision this as a short, light, exchange of the information we need to plug technologies together without knowing the details. I see it as smaller than, but perhaps derived from, ISO-61850. It includes some basic safety information. It includes estimates of reliability and capacity. It may include some of the “price attributes” (Am I a source of carbon-credit eligible power?). SG Energy Interoperability includes critical Demand Response, i.e., non-market emergency curtailment of energy. A draft of the Energy Interoperability TC Charter is attached.
- SG-Load Control: The OASIS standard oBIX offers an extensible WS framework for communication with building control systems. OBIX defined a concept of Contracts, used to define higher level interactions. The ASHRAE BACnet Load Control Object offers a model for building systems to report on their energy use, to negotiate responsiveness, and to make load shedding agreements. SG-Load Control would build on the BACnet model to define a web service standards for contacts as defined by oBIX
- SG Telemetry: What is going on on the grid, and where is it failing. I recommend that we apply the watches, trends, and messages of oBIX into this critical area.
- SG Remote Operation: This one may be a literal transform from the ISO 61850 standard for substation communications. To the extent that SG Remote Operation moves into web services, it should apply interaction patterns and data models of oBIX.
- SG Curtailment. Sometimes, no matter how you plan, stuff happens. The daily temperature is 5 degrees warmer than expected. The turbine seizes. A truck drives into the transmission tower. Shed load NOW! Prices and markets for curtailment have been evolving rapidly; perhaps this addresses the grid integrity issues more directly. SG-Curtailment is part of the deliverable of the Energy Interoperability TC.
- SG Quality Of Service (SG-QOS): Participants in the smart grid must exchange information about reliability and performance. QOS information must be exchanged both as a promise and as a result. We may be able to adapt the Business Process QOS (BQOS) work from the EERP TC
- SG CyberSecurity: Security issues need to be integrated within every TC from the beginning—and not merely a veneer layered on after the fact. We need a separate security toolkit/framework, perhaps a profile from current fine-grained security standards, key management, and related areas. SG Telemetry may be an area to start defining so the broader integration of physical security, fine-grained networking and commercial security, and situation awareness technologies can be brought to bear.
Keep those comments and suggestions coming...