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.

BSI Part 3: The Metadata Problem

After the ASHRAE meetings, and during the AHR conference, several of us are getting together to discuss building system metadata. The goal is to define interfaces to support quick fast integrations of building systems into the wider world. This is the third of several posts describing this interface. Drop me a line or watch for announcements from LONmark if you want to join us for discussion.

Metadata refers to information about data. While control systems for buildings can offer up an impressive amount of data, it takes far too much effort to figure out what it means. In a medium-sized commercial building, tens of thousands of points can take a month to unravel before useful integration with the businesses and lives of the people who occupy those buildings is possible. Throughout all the integrator must understand the technologies in use in that building. At the end, the integrator produces proprietary results himself.

Most of that integration effort is in deciphering what those information points mean. Is that point an internal point, useful only to the HVAC professional, or does it represent a room temperature, or oxygen level, of interest to the building occupants. Do these points describe one air handler or ten? Are all air handlers fed by the same compressor? What space, which means what business services, does each system support? The answers to these questions can be discerned by the trained professional, with the blueprints in one hand, and years of experience in the other. Today, they cannot be reliably determined by machine inspection.

We need a relatively few profiles to pull this off. Or maybe we just need some rules about profiles, and a place to create a repository. Too many profiles could just recreate the chaos we have now, in which metadata is all free-form tags.

There are several existing profiles for communicating with energy meters; we need to get to one. The profile model should be able to indicate what systems are behind it, by reference, to the discoverable catalogue of building systems and spaces. Whether you call it live load, or plug load, circuits and the space they support can be described in PLIie. Everything, of course, should be tied down to the space or spaces it supports.

BIM standards contain standard descriptions for how a space is used. The links to space, offer potential keys into business directories and business schedules.

The place to start collecting this metadata is during commissioning. COBie (Common Operations Building information exchange) defines a family of information models that can be handed over from a construction Building Information Model (BIM). These include a catalogue of building systems and the spaces they support. As retro-commissioning starts to follow commissioning standards, we would begin to get the benefits of the BSI-enabling metadata in existing buildings.

BSI Part 1: What is the Building System Interface?

After the ASHRAE meetings, and during the AHR conference, several of us are getting together to discuss building system metadata. The goal is to define interfaces to support quick fast integrations of building systems into the wider world. This is the first of several posts describing this interface. Drop me a line or watch for announcements from LONmark if you want to join us for discussion.

In my smart grid work, I began describing each end node as a microgrid. A microgrid is a self-contained entity responsible for managing its own energy use, generation, storage, conversion, and as a last resort, market operations. This model eliminates direct grid control of buildings. Maximum grid incentives, all delivered to a single energy services interface (ESI), the locus of market bidding for the building.

The ESI is the external face of the participants in smart energy. The ESI facilitates the communications among the entities that produce and distribute electricity and the entities that manage the consumption of electricity. An ESI may be in front of one system or several, one building or several, or even in front of a microgrid. In keeping with service integration principles, there is no direct interaction across the ESI.

Today, an ESI is most often on the outside of a building system. The leaders in commercial energy management, companies like Target, put the business between the ESI and the building systems. Target evaluates energy use, and changes in energy use as normal business decisions, and building systems respond to business operations. Target though, is unusually aware of its decision processes, has many nearly identical buildings, and has strict commissioning standards. For the rest of us to be like Target, we need a Building Systems Interface (BSI).

The BSI must expose several services. New systems will certainly incorporate the market-oriented interfaces of smart energy, for use inside the building microgrid. Other services will interact with the business, linking corporate calendars to building operations. Another will request and consume weather information; if nothing else, a data center should take advantage of a cold winter such as this to limit cooling loads.

Systems must tie their information to the space that the enterprise inhabits. It is not enough for points to self-describe themselves as an air handler—that air handler must describe itself in terms of the service it provides to a particular space. Space is what the building systems support, space is what the tenants recognize.

There is an enterprise service that links between the occupants and their activities and the BAS and its performance. It communicates to support business activities while using the common schedule communications developed for smart grids. It is aware of the market conditions and deals made with the grid though the ESI. It knows whether the volatile energy of the renewables-based grid is scarce or abundant. It can report back to the enterprise how and where energy is being used right now.

Even live-load, or plug-load, must be able to describe itself in relation to space. Panel sub-metering and BIM-based circuit tracing (PLie – panel layout information exchange) put even the coffee pot and copier as part of the BIM model for energy use. Even home appliances must be participants.

BSI and a blast from the past

Every now and then I run across an old email that I have long forgotten, but speaks to my current activities. I think that this comment, written long ago in the oBIX forum speaks to something I need to return to. Jon recently gave me and WS-Calendar and EMIX some excellent advice on on creating standards for re-use and extension.

-----Original Message-----
From: Considine, Toby (Facilities Technology Office)
Sent: Wednesday, January 05, 2005 6:36 AM
To: 'jon.bosak@sun.com'
Cc: 'Grobler, Francois ERDC-CERL-IL'
Subject: RE: oBIX Guiding Principles

There are parts of Control Systems that are very business oriented. If an embedded control system detects that it needs maintenance, and can submit a maintenance request to an identified partner, clearly that work order looks like a normal business transaction.

Meeting and occupancy schedules might look like UBL (room will be occupied tomorrow from 2-4; use oBIX to inform HVAC, Access Control, Intrusion Detection, A/V management control systems. Read the Electric Meter before and after the meeting). Does the UBL standard extend the ICAL standard, or subsume it or...? Clearly, there is a benefit for scheduling functions to re-use commonly implemented scheduling requests.

These functions are in the future. What oBIX has to start with doing is exposing the event driven world of controls to the enterprise. For the most part, this starts with state. What are all the room temperatures on the 3rd and 4th floors? For how many hours did the compressors run today?Which areas of the building are currently secured? Some of this information is creeping into QOS agreements in real estate, and so intersects with the work of OSCRE (Open Systems for Commercial Real Estate). To my knowledge, UBL does not really include the nomenclatures for this because this is outside of the normal business functions. Am I wrong? Can you refer me to any relevant portions of UBL?

I think an early use for oBIX will be to provide a platform on which GRIDWISE (www.gridwise.org) type applications are built. That may be the first place where standard UBL functions hit, as price incentives are offered to buildings on the spot market to forefend brown-outs and the like. That feels more like bid/delivery/request rebate.

The construction industry has long had a separate open standard for construction documents, known as the IFC (Industry Foundation Classes) developed by the International Association for Interoperability (http://www.iai-international.org/iai_international/) and already required in many international construction projects. The IFC space includes construction documents, spatial data, spatial modeling, etc. The EU, in particular, leans heavily on this ISO specification, particularly in the Nordic countries. The largest landlord in the world, the GSA, has mandated that all transmittals for the design, construction, and acceptance of buildings. The closely related GBXML (Green Building XML) is a lightweight variant of IFCXML focused more on performance issues. GB Modeling, using GBXML for transferring building performance data, is required for those projects that wish to be designated as compliant with programs using words such as "sustainable" and "LEEDS". We have long considered that IFCML and the closely related GBXML were our most important shared spaces. Is there a defined interface/mapping between IFCXML and UBL?

Thanks for your comments

tc

-----Original Message-----
From: jon.bosak@sun.com
Sent: Tuesday, January 04, 2005 9:20 PM
To: Considine, Toby (Facilities Technology Office)
Subject: Re: oBIX Guiding Principles

| G) If, as seem likely, this document is adopted as an OASIS standard,
| I recommend that we steal freely from this document, reusing as much
| as we can in our rules for developing subsidiary oBIX services as well
| as in the core document. It is well written and defends its decison
| in a language that is focused and apropriate for the enterprise
| developer.

Since UBL is probably going to become the dominant standard for international trade documents, why don't you just adopt the UBL schemas and have done with it? After all, UBL is based on a pretty widely adopted specification (xCBL 3.0) that was developed specifically for electronic marketplaces. If there are any data elements missing from UBL 1.0 that are needed for oBIX, we can probably include them in UBL 1.1.

Jon