Service Oriented Scheduling (Part 1)

Some interesting 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-machines scheduling and optimization of resources.

In a later note, I will describe how EMIX Terms add critical additional information for service oriented interactions in the Internet of Things.

Using COBIE as an integration interface

At the meeting of the NIBS FMOC in Baltimore this spring, challenges in expanding the use of COBIE were again at center stage. The National Institute of Building Science (NIBS) is a public-private partnership to advance the identification and resolution of problems and potential problems that hamper the construction of safe, affordable structures. In recent years, one NIBS committee has led efforts to develop a national building information models standard (NBIMS). NBIMS is more than technology, and concerns far more than a 3D building model; BIM it is the basis for re-engineering the processes used in facility design and construction.

The Facilities Maintenance and Operations Committee (FMOC) of NIBS promulgates best practices in building operations. BIM has traditionally focused on initial building cost. Initial cost, though, is only 15 to 20% of the life-cycle cost of a typical building. By using information known during design and construction to improve operations, one can reduce costs, extend the useful life of buildings and building systems, and improve the quality of services provided by the building. Many have characterized BIM and COBIE as of interest only to the long term and institutional owner. However, even for the short-term owner, improved services can improve tenancy rates; improved revenue and reduced cost improve the building capitalization in any market.

COBIE consists of several simple schedules of information that describe a facility. There are limited and defined relationships between these tables. COBIE names all rooms and their size, furnishings, and finish. COBIE catalogs building systems associates them with the spaces (rooms) they support. The equipment associated with each of those systems is listed, and for each, the faceplate, spare parts, and recommended maintenance schedules.

COBIE was originally conceived as a one-way transfer from Design/Construction to Operations. Most design and construction software today can export COBIE. Today that information is often inconsistent or incomplete. Good commissioning practices produce information very similar to that delivered by COBIE; COBIE has found some acceptance as a means to hand over commissioning information when there is no BIM. Most systems that import COBIE today are roach motels—information checks in but it doesn’t check out.

Two-way COBIE, that is the ability to import and to export COBIE, is an intriguing new area of concern for the FMOC. Most systems that import COBIE today are roach motel systems—information checks in but it doesn’t check out. The initial commissioning of many of today’s was inadeqaute. Retro-commissioning names the process of inspecting and cataloguing an existing building as if for the first time. Retro-commissioning is associated with energy audits, with capital renewals, and with changes of ownership. A computerized maintenance management system (CMMS) that can export COBIE provides a starting point for retro-commissioning reducing the cost and improving accuracy.

Round-tripping COBIE presents some programming challenges for any system. In simplest terms, a system that exports COBIE for Building containing 100 rooms, and re-importing COBIE with 99 rooms should not now indicate that the building contains 199 rooms. At the same time, the maintenance management system should preserve history through the re-import.

Most building maintenance and operations uses different software for different business functions, and it is difficult to align and validate the information across products. While each part of an organization would like to use best of breed software, doing so today creates islands of information. It is routine to have separate systems to support maintenance, tenant management, event management, housekeeping, catering services, capital renewal, amongst others. Outsourcing and sub-contracting introduces the additional complexity of multiple organizations.

Each of these applications can potentially benefit from importing COBIE information. Some are interested in subsets only. Once the information is in place, the information in these systems begins diverging starting with the first day that they are used.

COBIE can serve as a standard basis for exchanging information between these systems. Changes relevant to all aspects of building ownership and operations can originate in any of these systems. Government and institutional owners face additional issues introduced by space auditing. If each system supports two-way COBIE, this information can flow between business systems.

Last month, I wrote about BIMCards, which use COBIE as the basis for integration between enterprise schedules and BAS scheduling. It is a well-known practice to use the semantics from one space as the ontology for an adjacent space, that is to provide meaning to what otherwise might be a mere catalogue. Today’s building systems are rarely strategic, because while they may incur many expenses, they do not express anything meaningful to the primary business of the facility. BIMCards names a method to use COBIE to create on scheduling ontology for building systems.

COBIE also provides a link from to the business value of facilities operations. Each business has its own ontology, that is, its own value proposition. For businesses that provide building-based services, that value proposition flows through the spaces in those buildings. COBIE-based integration, when extended to the building systems, links building system operations and performance directly to the business ontology.

A business that clearly understands its value proposition can react quickly to changing conditions. A business that understands how its building systems fit into that ontology, is a business able to easily participate in smart energy. COBIE-based integration fits building operations and building systems into the core business of the building owner and occupant.

Another ontology, a way to find meaning for building systems is to align with the people in the building. A tip of the hat to Michaela Barnes who sent me a link to the WristQue, a portable sensor and identity wrist-band for interacting with buildings. Just search for it.

Easy integration of the Internet with Things: Calendar Subscription and Syndication

I use Outlook in my day to day life. It shows me an aggregate calendar, with meetings I accept at the office (one account) meetings I accept not at the office (another email account) and two corporate calendars: one based in Exchange, and one in SharePoint. When I was working on the national smart grid roadmap, my Outlook showed the calendar of that SharePoint project as well. In Outlook, I can turn each calendar off or on, and when aggregated, each appointment was a different color by source. I live by Calendar aggregation.

In my Phone, which happens to be an Android, I used to have a calendar for each email account. Each has different security set-ups and realms. Each source has different policies about sharing calendar on distributed devices. It was easy to miss appointments when on the road as I switched between different companies.

With an overnight upgrade pushed out by my phone company, this changed to a single calendar. That single calendar is color coded, showing the source of each event. Some of the things that are on my phone are “not quite meetings”, when GMAIL has interpreted something as a meeting although I have not accepted the meeting. The rules GMAIL uses for this appear to be similar to, but not identical to, the workings of Google Calendar.

Because I speak regularly in front of large audiences, I am always working in concrete examples of abstract issues. I use my phone as a prop when talking about the problem of smart homes and vehicle charging. The narrative goes as follows:

• This phone manages an ever changing set of security issues as dictated by my various calendar providers. Those security changes (passwords, policies, …) are things I do not want to build into my home. “I changed my password at work today—now I have to tell my refrigerator and my car” is not sustainable.
• Whatever the security policies, the calendar that I can see on my phone is semi-public, i.e., it has already been de-securitized for sharing. It may be a top-secret meeting, but it is now in a state wherein I can look at it over dinner and say “No, not next Tuesday.” It is, in effect the external face of my personal (corporate) schedules
• The phone is a “syndication point”; it syndicates each of the calendars that I subscribe to, to tell me what to do today.
• The OLED screen on the magnetic computer stuck on the front of the refrigerator is another syndication point. It can subscribe to feeds from my android, the wife’s blackberry, and the kid’s iPhone, to develop the syndicated household calendar.
• Note that each syndication point chooses what to share with downstream subscribers; the household calendar does not necessarily look like the sum of the upstream calendars. Policies about privacy and sharing, and key words that make a meeting “private” are managed upstream, and each syndicator can apply its own policies atop those.
• There is no need for end-to-end security, no need for shared secrets the length of the chain.

I may choose to create additional information within the house. The party, family church, Sunday afternoon football viewing may all be events originating in a house-based schedule and not appearing in any of the subscribed calendars. Or perhaps the household calendar is just another subscribed calendar fed into the syndication. That is an implementation detail that no one but the magnet-on-the-refrigerator computer needs to know.

My phone Calendar, then is an aggregation of calendars that I potentially syndicate out to other calendars.

If we flesh out the needs of the electric car, negotiating expensive fast charges and cheap slow charges, it needs to negotiate only with this household schedule. It may learn its own secrets, such as how far I drive when I go to choir practice. It may learn off-the-schedule stuff, such as that I frequently stop at the bar (an extra 10 miles of driving range) on the way home from choir practice. It does not need to share that information upstream to my house, or with my electric utility. It merely uses this information itself to make decisions autonomously about charging strategies.

The car has its own calendar for sharing. Based upon what it has learned, not only about my schedule (from the house) but about my habits, it can create a schedule of charging needs. It syndicates *that* schedule to the house, and negotiates with the house for access to market. The house syndicates the requirements from all the systems it supports, and uses them to guide it market position in energy.

The same calendar may be syndicated in different ways. The house subscriptions may include multiple children of the same syndicate. The house may learn from its subscription to my Android that I am out this evening, and do not need heat and lights in my rooms. The house may learn from the Calendar in the car, that I need power before this evening to support that same trip out. It is OK for the syndication to affect the houses buying position twice. There is no need for round-tripping or end-to-end tracking. The information is consumed, decisions are made, and market positions are created.

OK, this is a nice tale of autonomous systems relying on aggregated schedule streams to create time-dependent market positions. It is time to start thinking about Calendar Subscription. Aggregation, and Syndication, and of touch-less integration with the Internet of things.

Scheduling Resources and Operations with BIM

Recently, I wrote of standards for calendar synchronization, vcards, and directory services. This week, in a meeting on iResource, we explored the Enterprise IT perspective on the same issues. Today, I will place these two views side by side, and look for a solution.

In enterprise calendaring, conference rooms were originally added to corporate address books as if they were another person. An account was created in the corporate directory for each conference room, albeit an account that lacked an employee ID. This account was assocated with a calendar server and perhaps an email account. Conference rooms were set up Justas were senior staff that do not manage their own schedule. Anyone could invite the conference room to a meeting. An assigned administrative assistant received all schedule requests.

Over time, this process became formalized and these accounts were flagged as Resources. Resources in mail and calendar servers may reject or discard all email other than schedule requests. A Resource may automatically accept all requests it receives, or it may automatically reject all requests when already scheduled. Tools, projection equipment, phone bridges, and office vehicles are all often scheduled as Resources. Some systems automatically set the Meeting Location to the display name of the Conference Room.

Now Resources need more definition in Enterprise scheduling systems. To the enterprise calendar world, a Resource might ebe A Conference Room, a Phone Bridge, a Projection Screen, possibly a catered Pot of Coffee—in the Scheduling World, I might need to invite all 4 to a Meeting.

Details:

• Some Rooms have a Projection Screen and Some do not.
• Some Rooms have a permanently installed Phone Bridge. Some Bridges can be booked and an event support staff will put one in the room. Some rooms may not have a phone connection so even if the Bridge is brought in, it will not work.
• Catering is based in the North Building, and only North Building and its immediately adjacent buildings are capable of meeting the Coffee Pot requirement.
• Each room has a capacity (10 people. 25 people. 400 people)

Task: Respond to “I need a room for 35 with a phone bridge, projection screen, and coffee”

In some cases, each Resource might also be associated with a fixed or variable cost. A Calendar server needs standard semantics to present candidate rooms to the organizer. I

In world of buildings, the source for this information is the BIM. When a building is completed, every room is identified by purpose. Each room is linked to the system or systems it supports or that support it. There are standard names for each amenity. These names and their values will define the common directory information needed for smart scheduling in enterprise calendar systems. That is iResource.

For smart energy and smart buildings, we need to ensure that this scheduling information gets to the systems that operate the building. Each room is fully described in BIM. BIM can use consistent information through design, construction, commissioning, and maintenance and facility operation.

But BIMs are large, complicated information models, with far more detail than is need for the calendar server. BIMs have more information than is needed for maintenance and operations, too. Fortunately, we have a format for transferring information from BIN to a Computerized Maintenance Management System (CMMS). This simplified format is the Common Operations Building Information Exchange (COBIE). COBIE includes lists of all spaces [rooms] as well as the fixed and movable assets identified in each spaces.

Once the resources match in the building systems and in the enterprise calendar server, we can use standards-based synchronization to align schedules within the two. Building systems are notified automatically of the 2:00 to 3:00 meeting for 25 people in room 207. A noteworthy aspect of this approach is that the catering service can be notified ("Coffee for 25 in room 207") with a precisely equivalent synchronization with the calendar service hosting their coffee service.

It has become a standard function for BIM software to export a COBIE file. Many CMMS systems routinely import COBIE to define new buildings; a few are themselves able to export information using the COBIE format.

IResource should use the attribute names and values defined in COBIE. These attributes then become the basis for Resource directories, and this means the basis of a vCard standard for building-based Resources.

Standard vCards and directory services for building-based resources promise to accelerate smart use of buildings, smart operation of buildings, and smart scheduling of buildings. vCards provide a basis for standardized synchronization services between enterprise calendars and building system calendars. Using the existing COBIE specification as the basis for service vCards will make the standard arrive sooner and improve completeness and accuracy of information.

Dr.Bill East at the Army Construction Engineering Research Lab (CERL) kindly directed me two three standard models, for the duplex, office, and clinic.

http://buildingsmartalliance.org/index.php/projects/commonbimfiles/

http://buildinginformationmanagement.wordpress.com/2012/01/10/cobie-and-bamie-specifications-released/