Finding a Needle in the Internet of Things (part 2)—Buildings and Building Systems

In a previous post, I described how vCards are used throughout standards-based scheduling and calendaring systems. Many different vCard standards coexist in today’s organizations. I also described how directory services, especially LDAP (the Lightweight Directory Access Protocol), are the well-established means to enable wide secure access to the information in vCards. In this post I discuss current efforts that will expand these existing standards to support buildings and their systems.

The most frequently scheduled building-based resources are public rooms and building systems. Public rooms are invited to meetings as are other attendees. Smart buildings can optimize energy use while preserving amenity if they know when and by whom the building will be used.

An enterprise scheduling may include hundreds of schedulable conference rooms. These resources are generic to some extent, but the potential scheduler would like to filter the list. Show me the conference rooms that are near me, and that will seat at least 8 people, have an internet connection, and have a projection screen. If there is a cost, show me what each costs per hour.

Two things stand in the way of adding this as a standard function. Today, there is no standard for what the names of each of these features is. In other words, there is no Resource vCard standards for rooms. The second is that there is no source for this information. Few want to take on an additional data maintenance task to enter this information or to keep it up to date. Fortunately, there is a solution to both of these problems, and that solution is BIM. More particularly, the solution lies in COBie Lite.

COBie Lite describes a strongly typed and validateable data model. COBie Lite has been stripped of all process, it does not matter what the source of the information is. The information in COBie Lite can be exported from the BIM used to design and build a building. COBie Lite provides a formal definition of the information that should be collected during commissioning. COBie can be imported into all of the major Computerized Maintenance Management Systems (CMMS). Today these systems are roach motels holes of COBie—data checks in, it doesn’t check out. That can and will change.

There are many sources of COBie lite. In each of them, the information is created or maintained to support an existing business process. A standard transform of COBie Lite can produce all the information needed for a standard Resource vCard for rooms. I call this standard the BIMcard.

Building-based systems also face problems of dynamic integration. Traditional building management systems are highly proprietary. Even when fronted by standards-based middleware, say a Tridium JACE exposing oBIX, it is still hard to integrate with business functions in any scaleable way. Let me be clear what I mean by scaleable. A BAS might take one engineer one week to link up BAS and some fixed enterprise functions. To link up 5 buildings might take a single engineers 5 weeks, or a 5 engineers one week. If it was a scalable process, we might expect the 5 engineers could integrate 100 buildings in two weeks. If the buildings can integrate themselves, that number goes way up.

A common BIM-based model provides a path forward. A commissioning report can produce an equipment-only COBie-based BIM. If there is a building model from construction, no matter how incomplete, it can provide a framework to host that COBie-based BIM. A profile for Building System Resource vCards can be defined based again upon COBie Lite. BIMcards, then become the searchable entrée to the systems in buildings. It is not hard to imagine BIMcards for temporary equipment, wherein they can register themselves in the building.

Work Plan for oBIX 2.0

Some of you know that the oBIX Committee (open Building Information Exchange) is meeting again. The work is moving ahead on multiple fronts. We have separated encodings (XML and COAP) from the core specification. We are working on separate transport specifications for SOAP and REST (including JSON). We are doing a refresh of the core specification for consistency and conformance. I am most excited, however about the oBIX 2.0, the enterprise services.

The core specification (1.x) requires each oBIX server to provide a lobby. Clients can ask the server what is in the lobby, and thereby discover how to interact with the system behind that server. Contracts are special purpose agreements that are added to the lobby. Clients can invoke contracts by accessing the elements listed in the lobby. Vendors and integrators can add functionality to an oBIX server by creating contracts to add to the lobby.

Our current plan is to define enterprise services by specifying new types of contracts to place in the lobby. oBIX servers will then state which types of contracts they support, which encodings, and which transports. As of March 2013, we anticipate the following sections:

Energy

oBIX Servers are likely to participate in collaborative energy ecosystems including those managed by Energy Interoperation (OpenADR 2.0) or as described by ASHRAE SPC 201. We plan to incorporate information models and semantics developed to support the US national Smart Grid efforts, including Green Button. Potential contracts include not only energy usage reporting, but projections and commitments as well. We anticipate leveraging the existing OASIS Energy Market Information Exchange (EMIX) Specific information exchange requirements as defined in NAESB REQ 21

Advanced Reporting and Aggregation (Historian)

The historian does not scale well in its current form. A request for, say, a one year history on several sensors is larger and more unwieldy than it need be. It may be necessary to support variations such as projections. We do not want to break compatibility.

Alarm Logic.

This topic extends alarm contracts to include logic for alarms. If A happens followed within three minutes by B. If the cycle between occurrences of A is less than 5 minutes. This is in effect defining diagnostics with interactions between functions. If I am talking to 100 oBIX servers, I may want to apply that diagnostic to every AHU attached to each of them.

Building Information Models (BIM)

In buildings, control systems operate building systems. Building systems support the various spaces in a building, whether securing them, monitoring, them, or conditioning them. The relation between a building system and spaces in a building is described in a Building Information Model (BIM). oBIX BIM contracts will describe how an oBIX server will make BIM accessible, and how to apply BIM as a semantic framework for the control points.

Enterprise Scheduling

Enterprise Scheduling applies the semantics of WS-Calendar to schedule interactions with building systems. This includes a notion of service oriented schedules instead of the control oriented schedules as today. (Example: Request room at temperature by 8:30 rather than Request room to begin heating at 8:10). This is likely to use the same semantic frameworks as security, i.e., to specify a room rather than a thermostat. Enterprise scheduling is made possible in part by the BIM framework as described above.

Security Composition

oBIX 1.0 defines a monolithic model, all or nothing, for access to points and settings. This access should be limitable by role and by organization. Advanced security contracts will define a means to define policy frameworks for secure access to oBIX servers. This is likely to be an intersection of roles, i.e., integrator, operator, tenant, guest as applied to business function. In buildings, business functions are defined by the spaces they are in. The relation between building systems and space can be found through reference to the BIM.

We will not define a mandatory set of roles, or a mandatory framework, but instead define a means to apply notions of space (say a particular tenant) and of role to access to an oBIX server. We anticipate a means to discover the roles available on a server, to map those roles into a discoverable space, i.e. BIM. This topic includes addressing federated security, and may include how to apply SAML, XACML, and similar specifications to oBIX servers.

Please contact me if you would like to join in this work.

Slim BIM: The Middle Ground between Document and Service Part 2

In my last post, introduced Slim BIM and the critical need for shared configuration to speed development in the building systems. This post extends that conversation.

A report from NREL, delivered last Spring, defined the Building Service Interface (BSI), a standard for interacting with building systems from non-building applications. That report recommended that each BSI be able to share a light-weight BIM, i.e., to be able to provide on demand a description of the space it supports, the systems it controls, and the relationship between systems and space. In the future, this light-weight BIM is likely to be part of minimum commissioning standards to get LEED or other environmental certification.

Mary Ann Piette, Staff scientist at Lawrence Berkeley Labs and Director of the Demand Response Research Center, has called these light-weight models “Slim BIM”. Today, there are two well-known specifications for Slim BIM: COBIE and GBXML.

Green Building XML (GBXML) is already well known to the building automation community. GBXML was originally developed to prepare energy models. GBXML has an easily used schema that is maintained by the non-profit Open Green Building XML Schema (gbxml.org). GBXML has become the de facto standard for exchanging information between with engineering analysis tools. GBXML is typically produced by CAD software including applications from Autodesk, Bentley, and Graphisoft. GBXML is used by energy modelers, HVAC design tools, ductwork CAM tools, and many others. GBXML is so well accepted, in part, because its schema is specified using modern tools that are easy for software developers to use.

COBIE, the other Slim BIM, has found a harder path to wide acceptance. Much of the COBIE produced today is of poor quality and semantically incomplete. Within BIM, information is exchanged using the Standard for the Exchange of Product model data (STEP). STEP is able to convey almost any kind of information, including detailed 3 dimensional data. The problem is, most users of this information do now want complete specification and wide extensibility; they need terse, validate-able information exchanges. Most users do not want detailed purpose-built information exchanges developed slowly in committee; they need ready-to-use exchanges that suit a variety of purposes. COBIE’s slow uptake epitomizes the cultural and technical differences between the engineered world and commercial IT.

COBIE would face less cultural resistance if it looked more like other inter-domain information exchanges. Some proponents have claimed that there is a COBIE XML format already. COBIE was initially described as “a spreadsheet of the data you need to operate the building”. Accordingly, standard Excel templates for COBIE are available. Today, the XML representation of COBIE is the XML representation of a Microsoft Office document. As this format is not very useful, most COBIE is produced as hard to understand, hard to verify CSV files or STEP text. The only COBIE verification tool that I know is offered by Onuma Planning Systems (http://www.onuma.com/products/OpsAndCobieValidate.php).

The Army’s Construction Engineering Research Lab (CERL) is a pioneer in using construction information to improve building design, acquisition, and operations. To CERL, improved operations are central to sustaining facilities not only during lean budgets, but also to sustain mission support. CERL’s PROJNET system, used by thousands of organizations, is the leading producer and user of COBIE. PROJNET maintains an internal XML representation of COBIE, one that is not now part of the specification.

When CERL releases its XML representation of COBIE, I predict it will soon become the dominant form for information exchange. A version of COBIE that is as easy to use, and as clear to understand as the GBXML schema will find rapid acceptance throughout operations. CAD vendors that produce poor or incomplete COBIE today will up their game. Current CAD systems require requires a few simple early design decisions to be able to produce good COBIE; designers who skip that step will find themselves at a competitive disadvantage.

Even the mash-up approaches to BIM will benefit. A CMMS that can export well-formed COBIE will be able to export information to Cloud-based BIM. Mash-ups between 3D building models and energy management systems will become common and expected. Well-formed, validate-able COBIE will make building information more visible than it has ever been, visible to the right user, at the right time, with the tools of that user’s choosing.

As these approaches replace the one-time, hard to perform integrations of today, BIM and system integration will become rapid and easy. Cloud-based techniques will reduce the costs of technology changes within each building at the same time as they expand the owner’s awareness of these changes. Shareable configuration is the path to rapid secure service integration.

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.