Commercial Use of Live Energy Models

This is one of a series of posts on how the semantic expression in WS-Calender is beginning to affect buildings and smart energy. WS-Calendar recently completed its third public review and will soon be published as Committee Specification 1.0.

In a previous blog, I discussed new directions in commissioning; including commissioning that incorporates BIM, schedules, and continuous energy models.

Performance Contracting and the new Commissioning

Many building owners are suspicious of energy performance contractors because the performance contractor is both a player and a score keeper. Because a significant effort is required to understand the information in building systems, there are significant start-up costs. These costs, both in money and time, require that each contract include a significant minimum contract lengths over which to amortize the up-front costs. These up-front costs make it uneconomical for energy contracting to use a third party auditor to verify results.If the owner selects a new a new performance contractor, the up-front costs will be incurred again.

Standard semantic tags and ready access to a light-weight BIM can change this.

Imagine a market wherein a cloud-based energy performance contractor could offer same-day initial reports. That same market also supports a number of 3^rd party auditors, cloud-based, each able to independently assess the results of the performance contractor. Each of these parties can hook up to the BSI, read the BIM, read the tags, and begin analyzing right away. A potential energy performance contractor could offer the building owner a selection of third party auditors to report the success of the contract.

This competition between cloud-based services would drive rapid innovation. On one side driving costs down, on the other driving richer models. These models are likely to build upon two significant efforts currently underway. ASHRAE SPC201 would inform the models, and through the linkage of systems and space, become more nuanced. Schedule-based business assertions, as we are beginning to see in the links of WS-Calendar and the IFCs would make these models more business aware.

Continuous commissioning based on such a foundation would support an ecosystem of cloud-based service suppliers, each able to grow to scale.

Retail use of Live Energy Models

As we move in this direction, we move from information models that are tuned to reflect changed operating hours to models that can tied increased energy use to short term activities, including, say those associated with a sale in one portion of a store. That portion of a store with an ongoing sale may have increased HVAC driven by increased traffic or brighter lights to attract shoppers and display the merchandise, and other enhanced amenities. A side effect of the brighter lights may be increased heat load, thus causing still more HVAC requirements than at first expected.

The most respected retailers with superior operations are already using these sorts of models to fine-tune their special Sales.

Non-Energy adaptive re-use of new Energy Components

Because the approaches described above rely on the composition of multiple standards, they create components that building integrators can re-assemble to meet other purposes.

Emergency responders have long wished for a variety of interactive means to acquire situational awareness of the facilities they are entering. The standard light-weight building model described above is a natural basis for situation awareness sharing. During an emergency response, the goal may be closer to raw sensor readings than to energy use. Those sensor readings, like the performance information, cannot be interpreted without a framework that indicates the spaces and the business purposes where those sensors are located.

Common abstractions, business purposes, and frameworks are the foundations for policy-based interactions with any system. The business-purpose-based analysis of space and system and schedule, is a likely target for adaptive reuse for emergency-response based policy. In the simplest (and direst) case, the facility is on fire, every asset is at risk, and so every bit of information about a building might be shared. In a simpler case, if the Spill Response Team is responding to a minor spill in the warehouse, it is inappropriate to share with them acess to, say, a webcam in the executive suite.

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.

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

Engineering information is document oriented. Large documents, even sheaths of documents, are exchanged, specifying in great detail exactly what to do, and how to do it. Modern IT (Information Technology) is based on Services. Service exchanges are minimal, as small as can specify results, and do not specify the means of execution at all. For the last 50 years, IT has moved far faster than have engineered system, the things we can touch, inhabit, or ride around in. For the next 50 years, when engineered systems will need to evolve as fast as IT has for the last 50, we will need a middle ground, between document and service call. This is the challenge of configuration, shared configuration that will enable big systems to interact as nimbly as does IT does today.

Buildings are big systems, composed of big systems, that must interact with the IT-based systems of their occupants. The systems of the occupants will change many times during the life of a building. If we are to meet national and international energy goals, the collection of systems in each building will change frequently as well. These systems will interact with services, simple calls conveying only requests and results. Before they can communicate with each other as services, each must learn about the other. Each system must be configured with the information it needs to request services. This information must be non-specific, to avoid the complexity of details. This information must be specific, cataloguing service entry points and potential performance.

For buildings, designed by architects and engineers, the design and specification uses BIM (Building Information Model). These are traditionally very large and cumbersome files. The National BIM Specification (NBIMS) describes documents based on the International Foundation Classes (IFCs). The IFCs are two cumbersome for exchange, so NBIMS specifies Information Delivery Models (IDMs) for each structured hand-off of information, and a model view for each IDM. These information exchanges are detailed and overly specific. They rely on document-centric notions of XML from long ago, seen as a “replacement” for large the documents in SGML. The IDM for each stage of a project is different, even if the information is essentially the same.

The problem is, no one outside of architecture and construction uses these approaches, and few seem willing to adopt them.

Recently, members of the National Institute of Building Science (NIBS) have worked on the hand-off of information at the end of a construction project to the maintenance management system (CMMS). They have developed the Construction Operations Building Information Exchange (COBIE). COBIE lists the spaces and their fittings, the systems and the spaces they support, and the equipment in each system with its maintenance requirements and spare parts. The market leaders in CMMS each support COBIE import. Maintenance staffs have reported replacing weeks of error-prone hand entry with 15 minutes of COBIE import, and had their Preventive Maintenance (PM) and spare parts management ready to go.

Other systems could benefit by importing COBIE as well. Building owners often run many Line-Of-Business (LOB) systems, often selected by different parts of the company, from different vendors. Asset Management, Capital Renewal, and the Registrar’s Classroom Scheduling, each has its view of the core facility information in COBIE. An owner may outsource maintenance to several different businesses that need to share information. The enterprise scheduling software, used to schedule staff and meetings, has its own view of the same data. If each system is initially configured through the import of the same COBIE data set, if each system uses the same identities for spaces and systems, then these systems will be ready to exchange Service calls sharing expectations and requests.

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.