AutomatedBuildings.com Column - When Things Negotiate Schedules

The Internet of Things (IOT) is a hot phrase today, particularly when it is left undefined. The IOT has two jobs, to read sensors or to schedule processes. Sometimes the two are connected and essentially instant, as in when a light sensor closes a curtain. Most processes that are performed by things take a while, and face constraints. Building cooling can start in an instant, but it takes a while for the building to be cool. Generators may have a fixed amount of fuel. Some systems must be re-conditioned after so much run time. Others are expensive to start, so must run for a while once started. Just as scheduling people, for meetings and for phone calls, is one of the core functions of the internet, scheduling systems is one of the core functions of the IOT.

When we schedule ourselves, we keep a lot of information to ourselves. Several of us may accept a 9:00 meeting tomorrow. The parent may change when he drops the kids off at school. The traveler has to schedule a plan, and possibly a hotel. The telecommuter has to look for a pair of pants. None of that detailed process information is shared with the meeting organizer. Some participants may have an assistant who knows that information and accepts the proposed schedule.

For today’s things, we always expect to have assistants. Some person is expected to know the lead time required, and the ramp time. Some person is expected to know that the system will be off-line for maintenance this evening. That person will approve the schedules.

Just as fewer and fewer people have professional administrative assistants today, in the IOT we will eliminate most of that human approval process, and the associated requirement for process knowledge. The most significant interactions of smart energy are to align schedules, to not use too much energy when it is scarce, but to use all available when it is. The systems within an aggregation must coordinate their schedules and process cycles if they are going to operate within a precise fixed load curve.

It won’t be long until aggregations of systems become self-organizing, able to balance their needs for scarce resources and their requirements to provide services. New interaction patterns, and new business models, can be found by combining WS-Calendar and EMIX Terms. WS-Calendar is a specification for constructing web-services that incorporate iCalendar, the long-established basis for personal scheduling. EMIX is an information model built to support the exchange of market related information between suppliers and buyers of energy.

Service orientation names a pattern for systems interaction in which system exchange minimal information about each other. Service interactions do not specify underlying mechanisms and processes. A system that offers a service does not care which system invokes it; a service can be used by many systems. Service integration pulls system together in a manner analogous to how we build the web; we link pages and applications together without worrying what software operates each server. Service integration maximizes code re-use while enabling rapid evolution of systems.

WS-Calendar addresses the implicit assumption that all services are “instant”. Everyone knows they are not. A merchant might select a credit card processor because of a faster approval service. Still, the request is always “Approve this now!” WS-Calendar defines the messages to request “Do it tomorrow, at 9:00, and keep on doing it for one hour.” As we begin interacting with the internet of things, this capability will grow in importance.

The iCalendar family of standards is broader than the simple meeting request most of us are familiar with. iCalendar describes a family of message types: events, tasks, to-dos, et al. in the core specification, recently updated in RFC 5545. iCalendar also defines a pattern of building messages so that new types can be defined. Two new message types that are drawing interest are Availability and Polling.

vAvailability (all iCalendar message types begin with a “v”) describes how to indicate recurring patterns of time during which one is available (or unavailable). Depending upon application, other information could be included. For example, a plumber could publish a schedule (availability) with a labor rate for business hours, another schedule with rate for early evening and Saturday service, and still a third for overnight service. Availability can be stacked; that plumber can lay a short-term unavailability atop the other schedules, interrupting the standing availabilities with a vacation. vAvailability optionally includes an indication of granularity of schedule perhaps the plumber indicates a one hour minimum. Using WS-Calendar, we have a machine-readable way to advertise when a service is available for invocation.

vPoll addresses the process of “voting” for a schedule. An event organizer can send out a range of times (indicated with vAvailability) for a meeting. Recipients can rank the options, including pricing the various options. After polling, the decision of which time to select is still left to the organizer.

WS-Calendar gives us the semantic tools for machine-to-machine scheduling and optimization of resource use. WS-Calendar introduces schedules to service interactions. It is now straight-forward for two systems to negotiate operating schedules, and to contract for long running processes. If there are many choices for service provider, choosing the best service may take many negotiations. EMIX Terms can be combined with WS-Calendar service advertisements to enable peers rapidly to narrow the choice of service provider.

EMIX, or Energy Market Information Exchange, is a specification developed to meet the information needs of distributed energy markets. Production, distribution, and storage in power markets, in particular, are based upon physical processes and the value at the point of sale is dependent on the time of delivery. EMIX incorporated many semantic elements from WS-Calendar to describe market products over time.

Power generation, in particular, involves large machines, each with particular operating characteristics. Starting a generator may be more expensive than running a generator. Wear and tear may be driven by operating cycles. In EMIX, we took the relied on characteristics developed for use in wholesale power markets and simplified them. By simplify, I mean we removed the process knowledge. For service interactions, we do not want to know the processes, only the affects.

From a very large number of characteristics that affect how generation can be marketed, we came up with a short list of Market Terms. Using Market Terms, a Service can indicate whether it would be willing to accept an offer.

Operating terms describe limitations in how the mechanism behind the service operates. It may be unwieldy to provide the service for less than 10 minutes, or the engine may overheat after four hours. Operating Terms include:

•    Maximum Run Duration
•    Minimum Run Duration
•    Minimum Recovery Duration
•    Minimum Duration Between Invocations
•    Response Time

Schedule terms use vAvailability to describe when the service is available. A single system might offer several services that are identical except for the terms, and terms may vary by schedule. Again let’s go back to the plumber who may have different response times and rates based on time of day.

These are not only the terms of generation market, they are the terms for negotiations between any two systems, or even for the plumber I described above.

If the IOT is a means to negotiate the delivery to us of physical services, then it works similarly for business services as well. Using WS-Calendar and EMIX Terms, 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.

This model corresponds with the long time goal of 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 let’s move beyond rooms. The patterns of information and communication described above are common to the processes of business and people, which 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.

Medical scheduling coordinates many different business processes, many of them not in house. An expensive resource, such as an MRI system, is often scheduled day and night. 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.

Using WS-Calendar and EMIX Terms, a system can 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 be easily handled through the use of WS-Calendar and EMIX Terms.

The most interesting work will move beyond orchestration to peer-to-peer choreography. Systems that are designed to advertise and to consume services based on these information models when directed by an outside organizer, are ready to become self-optimizing in aggregate. 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.

Microgrids and other systems of systems can require less custom integration than today. Self-organizing and self-optimizing collections of systems will become the norm. These collections will respond to and anticipate our needs. It will start with systems that move beyond efficiency to doing the right thing at the right time. It will include new technologies such as distributed energy and electric vehicles. In the long term, it will move beyond energy, and even beyond other resources constrained over time such as water. It will spur market innovation by enabling rapid integration of new systems and technologies. And where it goes is anyone’s guess.

Events	Want Ads
Our Sponsors	Resources