Schedules for Things and Markets

Yesterday, I sat in on the final day of the Calendaring and Scheduling Consortium's semiannual conference (www.CalConnect.org). CalConnect is a consortium that promotes interoperability between dissimilar calendaring and scheduling systems. I was there to scout out their just unveiled xml serialization of ICalendar. I think we will use it a lot in buildings and on the smart grid.

I have written before that we need a simple way to exchange information about events. This is a quite different task than time synchronization. Events have duration and may evolve multiple participants. In the old Mission Impossible shows I watched while growing up, they would plan a series of events, often events that require close cooperation between several actors, whether they were good guys or bad guys. Then they would synchronize their watches and the drama would begin. CalConnect does not worry about synchronizing the watches, but about all the planning for activities that need to happen together.

In the enterprise-responsive building, rooms and access control should respond to normal business events in the building. Schedule a meeting for 9 people in Conference Room 2 on the third floor? Catering a wedding for 200 in ballrooms A and B? The building system should prepare that room to be comfortable by then, and plan for adequate ventilation to keep that many people alert. Enterprise responsive buildings can move beyond efficiency to doing the right thing at the right time.

On the smart grid, we will be constantly comparing events. Next Tuesday at 10:00 power will be expensive. The factory is able to sell excess cogeneration back to the grid during the lunch break, 12:15 to 1:00 five days a week. The office building can shut down early in response to the grid because almost everyone is at the sales meeting. The primary benefits of the smart grid are from aligning supply and demand, and thereby being able to rely on intermittent energy while avoiding expensive or "dirty” energy".

As people, we share schedules and meetings every day using ICalendar. Surprisingly, there has been no accepted standard for writing ICalendar in XML.

On Thursday, Steve Lees (Microsoft), Cyrus Daboo (Apple), and Mike Douglas (RPI) posted a draft of an XML serialization of ICalendar to the IETF (Links below). It will be assigned an RFC "real soon now"™. Steve also created a web based converter into which you can paste your own ICalendar object and get a translation.

I have some quibbles with the draft:

I would like to see the location (latitude and longitude) component of the specification use standards from the Open Geospatial Consortium. For now, they should use KML; you used KML the last time you pinned something to Google Earth. (Imagine all the concert listings in your town automatically pinning themselves to a map). I would like them to consider allowing other OGC defined objects—such as a polygon, tracing out the area affected by the event. I would even like to make this field multi-valued, allowing multiple points to be affected by the event.

The standards also includes the Uniform Resource Indicator (URI) as does the ICalendar object. You may be familiar with the more specific form of the URI, the Uniform Resource Locator (URL)—you typed the URL into the browser to get to this page. The word URI is the more general case and includes more options, including all URLs. I would like to be able to add a list or URIs to an event.

I would like to see the description be typed and multi-valued as well. When you are using a calendar, the description is the part of the message that may show up as the conference call #, the agenda, etc. In the standard this shows up as:

      <description>
         <text>
            Looking forward to a good discussion, 1-800-888-1234
         </text>
      </description>

I would like this the be multi-valued, and able to support more object types than text.

Of course, each of these multi-value issues (location, reference, description) would break backward compatibility. As they are not defined in iCalendar, they could not be converted back into iCalendar. These are not complaints; as I said above, that’s why people put drafts up in public.

I am very glad to see this one up in public...and I hope to incorporate their work into oBIX soon.

Intelligent Buildings talk to Smart Energy

As I write this, the Interim Roadmap for the Smart Grid has not been published. THis is a personal, un-endorsed view of how this area will develop.

Intelligent buildings filled with clever devices and intelligent systems will negotiate with the grid and with their occupants to provide new models for reliable power. The benefits to the grid will come from coordinating supply and demand using economic signals. The benefits to the buildings will be increased value by providing higher levels of amenities to their tenants and inhabitants for lower cost. The benefits to the tenants and occupants will be better services at the same or lower costs and more autonomy as they separate from grid dependency. The benefit to the clever devices will be longer life and more reliable operations from eliminating the power shocks that assail them now.

The benefits to building owners will be economic models that offer incentives to pay for improved equipment. The benefit to building integrators will be national markets based on common signals from the grid, allowing them to provide more services to those owners for less. The benefit to ventures and technology development will be the entry of all those building owners into the markets for generation and storage; those owners will offer a shorter sales cycle and more openness to innovation than ever will the utilities.

This requires a small simple model for interactions. To create this model, we must think clearly about the business process of each of these participants. Today, we have the virtual company in every niche of our economy. UPS and FedEx offer logistics services that are part of the internal processes of thousands of companies. Tomorrow we will have virtual energy services companies as well, assembled from the services offered by a community more numerous and diverse than today.

Each building will communicate with the grid by two services: the metering service and the energy management services (EMS).

The metering service (which does not necessarily mean the meter) will provide live and interval measurement of energy flows into and out of the building. This service will be symmetrical, meaning both the supplier and the consumer will be able to see the same information at the same time. The meter service will also be the end point of the energy distribution control system, providing telemetry to enhance customer service and downtime recognition.

The EMS will be the focus of business interactions. On the outside, the EMS it will manage the business negotiations for each building. On the outside of the building, the EMS will be the locus of energy market operations. Buying, selling, and price decisions will flow to and from the outside of the EMS.

On the inside of the EMS, developers and integrators will build applications to manage moment by moment energy use. The energy management applications will respond to the needs of the Industry, Office, or Home. The EMS will inform them of market negotiations on the outside. They will catalogue the devices and systems inside the building. They will marshal potential responses the smart grid market signals. They will share these responses with the EMS agent to inform its negotiations in energy markets.

A key service offered by the EMS will be to relay energy management services to external parties. Many businesses and homes will want to out-source their energy management; the EMS will support this. Some utilities will want to offer this outsource energy management to their customers. Some utilities will mandate, as they do today, that they accepting their energy management services is a condition of participating in certain programs.

I have written before on this blog, when discussing plug-in electric vehicles (PEVs), that eliminating regulatory barriers to retail re-sale of energy will help achieve some benefits of the smart grid. At the EMS, this means that sometimes there will be additional EMS systems below the EMS that talks to the smart grid. The educational campus, office park, and military base may have many buildings, each with their own EMS. Even office buildings may have an EMS in front of each tenant. Between the EMS at the edge of the grid, and each EMS below, there can be a whole new energy market.

Distributed generation and distributed storage are important aspects of the smart grid. The EMS must be able to marshal and generation and storage the building side to respond to market signals from the grid. If these resources are inside a building, then there can be a micro-market inside that building. On the base or campus microgrid, these resources may be directly attached, external to the buildings. In either case, the messages and market operations on the client side of the EMS should be the same as those on the outside.

The smart grid roadmap cites loose coupling, layered architectures, composition, and symmetry as critical design values. The EMS as defined above uses loose coupling and avoids direct control. Symmetry enables us to define the same services on either side of the EMS, and for the meters to report net use and net supply identically. Layering lets the conversation above proceed without ever mentioning data paths or transport protocols; it works the same whether the EMS is separately attached to the internet, or bound to the meter and communicating over utility infrastructure. Composition lets price and supply and value flow through multiple domains.

Smart Building professionals should watch the development of the EMS, and consider what new value we can deliver once we define the interfaces. If you want to participate in developing the interface, write me about the Technical Committees defining Energy Interoperability and Energy Market Information Exchange.

Smart Cars At Loose on the Smart Grid

I have written before of the challenges of software for electric cars at home (Smart Cars at Home on the Grid). Today I want to expand the domain of those cars into the wider world. The minimal car software will have some way to make electronic purchases as it drives across the town and the country. The better car software will do much more.

The electric car may recharge while on the road. It can also re-sell power when on the road. How it decides to do this must first be based upon what the car is doing. If I am driving to the beach, a drive of several hours me, then I am not interested in accepting any offers to buy my stored power when I stop for a Bo’s biscuit en route. My car needs to know and understand my travel plans.

Cars will certainly have fast charge as well as slow charge options. Unless in the dead of night, fast charge is likely to be considerably more expensive than a slow charge. Not all locations will offer fast charges. Not all locations will be connected to the grid. Not all locations will offer the same kinds of power. As a car drives from home to work to the public parking lot to the mall, as its driver visits friends and family, then the power market rules, billing, and security change.

The car’s energy management system (EMS) may well integrate with the car’s geographic positioning system (GPS). Today’s GPS can already tell you where the nearest gas station is, and the prices at many of them. Tomorrow’s car-based GPS should find stations for re-charging, including the location of the green re-charge, the fast re-charge, all factored by the remaining charge in the vehicle battery.

Too much time, and too much energy is spent on standards for portability of car identity. Current market rules prohibit resale of electricity by non-utilities. This market rule creates all sorts of complexity and rooms full of technologists and executives discuss how to make the charges from plugging in your car away from home go back to your home energy bill. This causes too much complexity. It breaks one of the oldest household transportation rules, that the teen pays for her own gas. It adds complexity on top of the more important life-style and service issues discussed above.

Even at home, the smart electric car will need a wider intelligence. The car may benefit from accessing weather predictions. Weather is the best predictor for predictor for tomorrow’s energy prices. Weather information is the best way to predict whether solar or wind power will be available tomorrow. Weather may be the best way to predict, in this household, a spontaneous desire to drive to the beach.

Wherever it goes, wherever it plugs in, the smart electrical car will be exposing itself to strange networks, with uncertain security. If the car manages its own charging identity, then it will need to protect its identity, shielding it except from the charge processing entity. The car will need to defend itself from strangers, while allowing extended family to re-program. The car must be able to request and accept software updates while defending itself, and its own system integrity.

Within the car, the car’s user management and credential management systems must be unable to take over the cars control system. The best cars designers are already moving to service oriented architectures within the car. This will make the move to defense in depth within the car simpler.

Dumb electric cars will be just tolerable. Good electric cars will engage the wider world as well as the home of the car owner. Software and information will be at the core.

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...