The Human Side of Energy Micromarkets

This post is part of the continuing Paths to Transactive Energy series. You can find them all listed by clicking on the matching metatag at the bottom of each post.

The Human Beings must have a say, or any model for transactive energy is doomed to failure. No model based on satisfying The Computers or The Grid will acheive prominence in the market. If optional, people will opt out. If mandatory, people will work around. The market is not a model for decision making, it is a pattern for interactions. In the abstract, semiotics does not determine meaning, only how meaning is conveyed. The interaction patterns do not determine the value of energy used at a particular place and time, they only determine how it is negotiated and conveyed.

Decision making must be local, driven by internal needs. Those decisions take place in the context of a larger market, but the larger market is not determinative of particular actions. People, whether at home or at work, will participate to the extent that it enhances their own satisfaction in some way, and transactive energy is, and must be, thoroughly agnostic about which layer of the Maslovian cake is driving decisions.

The occupants of the house, or of the business facility, determine the values of those systems that they use and how they negotiate. No one outside the house can know whether that spare refrigerator is deep storage or beer refrigerator, and if this weekend’s party makes the beer refrigerator and the ice-maker priority uses. (Note that I am not discussing the human interface that might make it useful or desirable to interact with the priorities of these systems—because these interfaces are outside the scope of transactive energy).

One system keeps things cool, within a range determined by biological safety or by personal preference, with limited flexibility over time of operation. One manages ice production, a pre-consumer that wants to acquire when power is cheap. Those two agents may have the same locus of interaction, let’s call it an IP address. They may be expressions of a single control system, of no open standard. They may not choose to share any temperature information with the EMS/BMS. The EMS/BMS does not care what protocols are used inside the refrigerator. In a similar way, a BACnet network with 5 AHUs may choose to represent itself as any number of agents (likely 1-5, but ventilation may come to market as a separate service than cooling) but not as a collection of BACnet points.

Transactive integration is the way to solve the problem of diversity of systems in the home. Developers of small microgrids aim to waste no energy, but struggle to develop drivers for every system. Energy device drivers for every CPAP? Every stereo system and television? Plate warming drawers? Expresso machines? In my home, the biggest energy user might be my well. The diversity of home systems is daunting. Each of them is valued for the service it provides, but each can have an economic profile, a meta-model, a prototypical pattern for its energy use.

This simplicity and abstraction is a benefit for the maker of the system or device as well as of the EMS/BMS. The owner can look at a device profile in a store or on-line and can say “yes, that is the way this device uses/stores/generates energy”. We can imagine heuristics, such as “you need some more pre-consumption devices to smooth your load.” The economic actor profiles become a way to discuss the systems as well as how they will interact when sharing resources.

Bidding for Schedules—VPOLL and VAVAILABILITY

Last week I watched live multi-vendor demonstrations using the new specifications vPoll and vAvailability. These extend calendar interactions to support live negotiations about schedule and performance. These negotiations can be machine-to-machine (M2M) or augmented by human input. These were not applications, these were live interactions between mainstream calendar servers. The testing used simple user interfaces, just enough to operate the tests. These simple information exchanges extend existing systems for schedule negotiations into automated polling and bidding.

As I have written before, I spent three days with the Calendaring and Scheduling Consortium (CalConnect) at AOL headquarters in the suburbs of Washington DC. Although the meeting was technical, it was against a backdrop of a scandal in the VA that is summed up, by the press, in the single word “scheduling”. Members of CalConnect went quietly about demonstrating their new work, based on iCalendar, that points to a new way forward, one that extends schedules negotiations into automated polling and bidding. CalConnect rules forbid any direct discussion of who was at the meeting, and what their precise interactions are.

CalConnect works to extend the reach of existing Calendar and Schedule systems (new specification development) while testing whether they work in exchanges between vendors with different code bases. Sometimes the code is changed, and sometimes the specifications.

ICalendar (RFC5545) defines a common grammar for creating information exchanges information related to schedules and defines a several such exchanges. The iCalendar event (vEvent) is familiar to anyone who has added a meeting to their calendar by clicking on a web site or opening an email. ICalendar defines other common exchanges such as tasks (vToDo) and alarms (vAlarm). OASIS WS-Calendar describes how to use iCalendar inside service oriented exchanges, with a focus on describing sets of schedule information that hang together in a series. There is a growing use of WS-Calendar world-wide in energy markets and smart grids.

vPoll is a new iCalendar exchange that uses iCalendar grammar to present a choice. Assume it is a simple meeting (vEvent). A vPoll could present a number of meeting times and ask the potential participants to vote. This is different than asking for a summary of when a recipient id currently scheduled (vFreeBusy). A recipient may choose to vote for a time knowing he can cancel a meeting. A recipient may be keeping that afternoon free for a visitor from out of town—even though nothing is scheduled. A recipient, for security reasons, may choose not to share any free-busy information.

vPoll further defines how responses go back to the originator. A poll typically includes an ending time for polling. The originator may choose to schedule the meeting in accord with the most votes, or when a few key personnel can make it or for any other reason. vPoll does not define the business rules or the application, just the messages and message pattern.

vPolls may be tied to prices rather than to votes. Maybe the single best price, or the three best prices, get invited to the meeting. Maybe prices determine the venue. The vPoll specification defines the BASIC Poll Type. Others will be defined later for specific use cases.

A recipient may choose to respond to a vPoll with vAvailability. Availability uses recurring patterns to indicate when something might happen, and what it might cost. Consider a meeting room in a commercial building. It can be scheduled during business house, using the calendar, for free. After hours, because of additional security and custodial needs, the same room can be scheduled for $200 / hour with a minimum charge of $300. These schedules can be expressed with vAvailability.

So far, I have described vPoll using only meetings. A Poll can also include tasks (vToDo). A task is often distinguished by its required completion time. Recipients can use their calendars to bid on various completion times. Presumably, bid for completion tomorrow will be more costly than a bid for completion next month. VPoll can gather the bids and present them to the originator, to choose one.

Most of us think of calendar communications (ITIP) conveyed inside email (IMIP). We open email and we accept the iCalendar request. At the CalConnect meeting this year, multiple participants demonstrated interoperable iSchedule, used for direct server-to-server communications. This promotes the polling described above from the personal to the enterprise. I will write more about iSchedule later.

The Right Time at the Right Place

Smart Energy uses schedule negotiation and schedule coordination to operate systems and equipment at the right time to take maximum advantage of variable energy supplies. As the internet of things grows up, it will move from gathering data from sensors to coordinating things to enhance our lives. The future of business breaks down into smaller entities with stronger missions that coordinate activities over time to support customers as if by a single business, only better. We all took steps closer to these seemingly simple coordination results, at a meeting at AOL headquarters.

For the last decade, the Calendaring and Scheduling Consortium (CalConnect) has worked to improve the interoperation of tools that coordinate schedules. We use their standards to run our personal and business lives, every time we accept a meeting request by email. Their work is critical to smart buildings and smart grids. This week, they demonstrated how to extend this work to support live machine to machine (M2M) schedule negotiations, including schedule auctions. My mind is buzzing with the implications.

Representatives of the US Veterans Administration (VA) were at CalConnect this week. The VA is in the news and under fire this week for failures related to scheduling and appointments. One can look to procedures and people and motivation, but under all is a cumbersome system that makes it difficult to accomplish some essential scheduling functions. These problems encourage employees to augment the system with a variety of out-of-system manual processes. These manual processes present opportunities both for mistakes and for gaming. Tragically, there was some of both.

VA management recognized the problems with scheduling systems well before the current scandals. It takes time to change anything so big. Last year, the VA held a competition to demonstrate standards-based approaches that could not only address the problems they have now, but can also prepare for more powerful stresses on their systems in the future. But knowing they had problems was not the same as knowing where and who the problems were. We have all found that out publicly in the last few weeks.

The story of the VA and open standards and how they hope to transform their monolithic systems in agile systems able to embrace outsourcing, insourcing, and distributed operations, is too long to fit here. I will write of it soon. I had the privilege of contributing to one of the competitors (my team came in third).  This week, the VA and those who hope to work with the VA were at CalConnect.  

CalConnect, now a decade old, ebbs and flows as does any organization. CalConnect was founded in a flurry of activity to address minimum capability cell phones, and worked through such problems as coordinating recurring meetings on a device too limited to compute once-a-week meetings. Today’s phones are more capable than personal computers then, and CalConnect has moved on to the problems of personal calendars in the age of social media. Calendar federation and social coordination bring new challenges.

Five years ago, CalConnect led the refresh of the aging standards for calendar information. iCalendar (RFC5545) is flexible and extensible, and describes key semantics and essential structure for everything you might see in your personal calendar. ITIP (RFC 5546) describes how to negotiate information between calendar-aware systems. You use it not only when you accept an email invitation, but also when that meeting is moved or cancelled.

Three years ago, CalConnect produced vAvailability, now moving to a standard in the IETF. (The Internet Engineering Task Force is the organization that manages the key specifications and communications of the internet.) . VAvailability is used in smart energy to advertise changing schedules for energy supply and for demand response. EMIX (Energy Market Information Exchange) defines contracts for Energy Reserves as financial options linked to vAvailability. OASIS developed WS-Calendar in close coordination with CalConnect.

But that is in the past. This week was exciting for the demonstration of new work that expands the tools for schedule coordination.

This week at CalConnect, multiple organizations demonstrated working interchanges of live schedule negotiations and schedule auctions. I will write more about the new standards such vPoll, CardDAV, and iSchedule later. The news is that this week CalConnect demonstrated three-server three-organization demonstration of standards-based schedule polling and auctions. The essential interactions for resource advertising and exchange were front and center. Direct server-to-server communications of schedules without the usual email were demonstrated, along with specific hooks for authorized interactions between web sites and personal calendars, and between trusted business partners.

Distributed schedule-based auctions are at the core of smart energy, including the budding efforts for interoperable transactive energy agents.

Standards-based scheduling engines will expand the reach and availability of specialized veteran’s services for today’s more mobile population. Open specifications for schedule negotiation can support more efficient and auditable queuing of complex scheduling requirements to be performed by multiple clinics. Distributed schedule-abased auctions will enable the VA to expand services and schedules to incorporate community resources far from the big VA Hospitals.

The next step of computer service is schedules for systems big and small to interact with our lives. The next step of business is improved provision of services across multiple businesses acting a single personal concierge, in medicine and in other personal services.

The tools for this were demonstrated at CalConnect this week. This work has powerful implications for smart energy, for medical scheduling, academic scheduling, and for social media. More later.

CalConnect invites interested organizations and companies to join CalConnect in moving the work
forward. www.calconnect.org

Service Oriented Scheduling (Part 3): Examples

In parts one and two, I described a model whereby long running processes, including physical processes, can be advertised and invoked within service architectures. A system can advertise when it is willing to offer a service, set prices for different schedules, indicate limitations in its ability to respond, and otherwise describe what it is bringing to market. A system seeking a service can efficiently compare performance characteristics and prices for acquiring / invoking these services. Client and server can negotiate when and how a service is provided. These information exchanges are at the heart of smart grid communications. In this post, I examine some other examples.

Long time readers know that I have long been concerned with getting buildings to respond to their occupants, or, in particular, to the schedules of their occupants. Many of us use our mail or calendar systems to coordinate meetings. It is common practice to invite the room as well, so the others can review the availability of the room for other meetings. Using WS-Calendar, one can post from the enterprise calendar of the resource [room] to the building automation system. This interaction does not require any service advertisement.

Sometimes the meeting organizer wants to compare several rooms. Some of the potential meeting rooms may charge rent or booking fees. There may be a lag the first time a room is scheduled on a given day, as the room is heated up or cooled down before use. Some rooms may use more or less energy, and the building automation through metering and introspection and weather predictions, may be able to calculate this energy requirement. If the building receives price signals from its energy supplier, it may be able to provide comparative prices for different rooms. These prices can be advertised in the service that books each meeting room in a building. A room can be scheduled with less advanced notice than it needs; when this happens the organizer can be notified that the conditions offered by the room will be sub-optimal for some or all of the meeting.

But this information model is useful beyond energy, buildings, and rooms. The patterns of information and communication described above are common to the processes of business and people. Their use opens the processes of business and people to automated negotiation.

Maybe the local coffee shops offer meeting support services. One is less expensive, but needs one day’s notice. The other is more expensive, but can respond with a two-hour’s notice. A scheduling system can search out the options, and offer the organizer choices and prices. Just as the BAS was notified of a meeting for 20, so, too, is the chosen caterer. The service provided by the coffee shop may be a process that arrives with coffee half an hour in advance. The service request can be the same as received by the BAS. The facility’s housekeeping service, whether in-house or outsourced, can receive the same notification, even though the service it offers is to arrange the furniture in advance and to clean up afterwards.

This pattern is a general pattern. Consider scheduling medical facilities. An expensive resource, such as an MRI system, is often scheduled day and night. A one-hour apointment using the MRI may require considerable set-up time. A single patient visit may involve multiple groups with multiple lead times and costs that vary by time of day. Medical groups may provide disabled veterans with transportation to and from the hospital. This transport service may be provided between 7:00 AM and 3:00 AM by in-house staff, requiring three-hour’s notice. After hours, the group may arrange for taxi or medical transport service. Depending upon schedule, patient medical state, origination and destination, and costs, the scheduler may be offered a number of decisions. The software presenting the choices needs only a limited amount of information to filter the services and to present them to the scheduler.

For each of the examples described above, a system is able to select from among services advertised, by schedule, by price, and by requirements, and narrow down to services that fit the need. Such a system may make a final decision of which service to use, or can present the final candidates to an end user with properly distinguishing characteristics. The distinguishing information can easily be exchanged using WS-Calendar and EMIX Terms.

In today’s new economy, people are inventing their own jobs based on radical outsourcing. New service markets are being built around services such as TaskRabbit. Local cooperatives such as LoadedBikes in Chicago offer just-in-time delivery to local and national services through aggregation of peers. Within a class of service, the WS-Calendar and EMIX Terms provide the information needed to select services and to assemble seamless aggregates.

The common information models of schedule and of EMIX Terms are the foundation for even more interesting applications that can be built using peer-to-peer interactions. Peers can compete for constrained resources over time, trading slight changes in schedules using market-like interactions. Because of the simplicity of the interactions, systems assembled in this way can be self-integrating and self-optimizing. This offers interesting possibilities for microgrids and other systems of systems. That conversation is out of scope in this series, but it can begin through thinking about these common information exchanges.