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.

Podcasting Open Source Smart Energy

The week before Christmas, I was interviewed by Phil Windley of itconversations.org. The conversation started out about schedules for the internet of things, but was published under the title Open Source Smart Energy. I was coming off a cold, and sounded like a frog croaking, but I enjoyed it, especially because the interview also let me meet Udell, whose work I have long admired. The conversation covered many of the high points of smart energy, including enterprise interaction, demand response, microgrids, and transactive energy.

Jon is a noted blogger and podcaster himself; known for both his own Interviews with Innovators Friday Podcasts as well as his own work with IT Conversations. Jon is known for his work with Calendars, especially the Elm City Project. Elm City look to turn computers calendars on their heads, from the collections of specially formatted emails most of us use now, to shared resources that one subscribes to. Jon advocates that the calendars published on the web, for community organizations, businesses, schools, clubs, museums, et al., be machine readable. Once they are machine readable, other web sites can aggregate and publish then in combined formats.

Elm City calendars are always up-to-date and do not rely on local copies of schedules published long ago. Elm City sources take control of their own public presence and schedules. These schedules can be aggregated, re-published, and re-purposed. Jon’s vision of the social use of calendars influenced my own views on schedules for the internet of things and smart energy.

For the impatient, here is a quick guide to the podcast:

• First 40 minutes, WS-Calendar and VCards and developing notions in the open source world about directories for services.
• 32 minutes: VCards for Services and Directories.
• 45 Minutes: On-Line appliance communication models.
• 48 Minutes: ASHRAE SPC201 and Minimal Knowledge for smart energy
• 49:50 to 1 hour: Demand Response, Consumer Choice, Decomposition or Energy, and the Open ADR Alliance
• 60 to 65 minutes: Microgrids
• 64 Minutes: Transactive Energy

For me, the most interesting focus was on building a community of open source using the interactions based on minimal knowledge that are at the heart of smart energy.

Schedule & Commissioning and the Future of LEED

As Chair of WS-Calendar, I receive a number of inquiries about the incorporation of time and schedule into other specifications. In particular, the wider visibility of VAVAILABILITY is attracting some interest. Occasionally these include fragments of xml, and inquiries as to how to apply this information.

WS-Calendar recently completed its third public review and will soon be published as Committee Specification 1.0.

NREL has recently released a report recommending tagging standards for building systems. This tagging standard is part of a larger recommendation on proper commissioning standards. The same report (http://www.nrel.gov/docs/fy11osti/50073.pdf) posits that a properly commissioned building system interface be able to offer up a light-weight building model, linked to these standard tags. This creates standard semantics for the building system as a minimum commissioning requirement for a future version of LEED.

Continuous commissioning is today limited by a market friction between changing the service provider. Initial set-up costs require analyzing the building system tags, reviewing the [paper] plans, and interpreting the variations between design and as-built drawings. A properly commissioned building should have resolved these issues already in ways that are re-useable by others. There is a growing sense that buildings should continuously update these energy models to maintain LEED certification.

Energy models predict energy use, and building systems are responsible for the energy use in buildings; these systems typically do not change much after commissioning. A changing energy models is caused most often by a change in business practices. Live energy models must be mappable to changing occupant business practices.

Business processes, though, are primarily linked to spaces, not to the systems. Some systems, i.e., food service equipment, may be linked directly to the business process; it may be that even these processes are stated most clearly through space use schedules. In a building with dynamic management of business processes, the energy models may need to be just as dynamic.

My work in communications for smart energy is concerned with communicating the volatility of energy supply and demand with prices. Facilities that understand their energy use will be able to control economic risk through committing advance purchases of energy on a schedule.

Operational scheduling of building systems in BIM promises to refine our understanding of energy use throughout the day. Linking building spaces to building systems will link energy use to business processes. Continuous commissioning makes energy models relevant throughout the life cycle of a building. Smart energy will create new value propositions for those who understand the schedules when they will use energy.