Construction-Operations Building Information Exchange (COBie)  

by U.S. ARMY Corps of Engineers, Engineering Research Developmental Center (ERDC), Construction Engineering Research Laboratory (CERL)



The handover of a new, or newly renovated, facility is celebrated by the project team, facility occupants, and owners. For those responsible to operate, maintain, and manage that facility, however, the work is just beginning. To start the facility manager begins by unpacking boxes of paper documents and retyping asset information and maintenance schedules into Computerized Maintenance Management Systems (CMMS). The pallets of boxes full of paper of operations and maintenance manuals and drawings shown in the figure below are typical of the requirements of contractors complying Unified Facility Guide Specifications 01 78 00 Closeout Submittals, and 01 78 23 Operations and Maintenance Data.

Facility managers have reported  that this effort may require man-years of effort to create and review and transcribe hundreds of pages of documents, validate the transcriptions and manually enter data.

To transfer the cost of this manual data entry from the facility manager to the construction contractor, UFGS 01 78 24.00 20 Facility Electronic Operating and Maintenance Support Information (eOMSI) requires the contractor to enter data directly into one specific CMMS.

photo of a storage room full of boxes and bins depicting the typical delivery of handover documents

Figure 1. Typical Delivery of Handover Documents

Even if a CMMS is used, mechanics need to search for information in these paper boxes to complete many of their jobs. Over time such documents are moved or lost which increases the cost to complete O&M activities and potentially increasing downtime of mission-critical facilities. A 2011 study  predicted that 8% of the annual maintenance budget could be saved if open-standard electronic information were available to the technicians before starting complex work orders. Such savings could allow man-years of additional work towards backlogs or needed renovations. During the life of a project the owner collects and recollects information again and again, transcribing and then losing the same information over and over.

In 2007, the Construction-Operations Building information exchange (COBie) requirements analysis report  proposed a new way for designers and contractors to directly provide electronic operations, maintenance, and asset management information as that information is created. Following an on-site study of COBie at Fort Lewis Washington, a proposed UFGS specification  was developed for design-build and construction contracts. Further investigation of COBie compared the life-cycle costs of current and COBie-based processes  and demonstrated that tens of thousands of man-hours or large projects are spent in performing redundant tasks trying to handle information locked-in documents.

Simply understanding, documenting, and proposing the information needs of operators, maintainers, and facility managers is insufficient to have COBie be used in practice. In parallel efforts the Engineer Research and Development Center, through the NIBS BIM Council (formerly buildingSMART alliance), worked to establish COBie as an internationally recognized open-standard implemented in over 30 Commercial Off-The-Shelf Software (COTS) systems.


COBie is a performance-based specification  for facility asset information delivery. Two types of assets are included in COBie: equipment and spaces. While manufacturer data for installed products and equipment may one day be directly available

, COBie helps the project team organize electronic submittals approved during design and construction and deliver a consolidated electronic O&M manual with little or no additional effort. COBie data may then be imported directly into CMMS and asset management software, again at no cost. The PDF, drawing, and building information model files that accompany COBie are organized so that they can be easily accessed through the secure server directories already in place at the facility management office. The federal government's requirement for delivery of Real Property Inventory (RPI) information may be met by COBie.

While the technical details of COBie can appear complex. COBie files are not intended for end-users. COBie provides system-to-system exchange of the space and equipment information without user intervention. Consider COBie and similar "information exchange" projects to be a kind of "ASCII for buildings." Today, people don't need to know ASCII to use a web browser, email system, word processor, or other software; the words just come along because of ASCII. In the same way, once we have achieved COBie everywhere, only a very few programmers will need to give COBie a second thought.

To make COBie as useful as possible COBie data is available in several formats. Software system exchanges during the design process could use the STEP Physical File Format (ISO 10303 Part 21) files conforming to the Industry Foundation Class (ISO 16739) COBie Model View Definition. When people want to look at the COBie data directly, and they do not want to learn to read complex STEP file formats, they can use a translation of data into a spreadsheet. Examples of COBie files of different formats, and at various stages of design and construction, can be found on the Common BIM Files page. COBie spreadsheet templates may be found on links at the bottom of the COBie Means and Methods page.

Exchanges of small bits of COBie data about individual assets is another type of exchange supported by COBie. For example, an entire file need not be exchanged simply to update the installation date and serial number of a specific piece of equipment. These individual COBie transactions can be captured through National Information Exchange Model format called COBieLite.


As in any other part of a design or construction contract, the quality of the product received depends on the ability of the designer or contractor to meet the specification. Before COBie, there was little need to clearly define the quality of the data provided since the volume of paper documents provided effectively prohibited more than a cursory review of the construction handover documents. Since COBie offers the possibility to automatically check the equality of electronic handover documents, the best owners will be sure they consider what to include in their COBie specification.

There are three sets of decisions owners can make to ensure that they get the information they need through COBie. The first is to specify the classifications they already use to organize existing CMMS data. If there is no CMMS data, COBie provides a default classification system, OmniClass, provided by the Construction Specifications Institute. The second set of decisions owners can make is to limit the set of scheduled information provided via COBie to only those assets that are actually managed or maintained. Finally, the owner can identify the specific properties to be mandated for each of these assets. Here again the default position is that COBie data simply reflect that data found on the drawing schedules. In most cases, such a level of detail will be well above the information currently captured. A brief video introduces COBie for owners.

From the designer's point of view, COBie data is simply the compiled set of all the schedules found on design drawings. Design software has been working hard since 2007 to ensure that they can export COBie data that matches their drawings. To ensure that design schedules can be properly exported to COBie designers should follow the instructions provided by their design software product. This brief video introduces the topic of COBie for designers.

From the contractor's point of view, COBie data is simply a way to produce construction submittals so information does not have be repeatedly copied and re-organized. Development of COBie data for the contractor should, if done correctly, also eliminate the need for equipment surveys. Properly compiled and organized COBie data also automatically produces O&M manuals. This brief video introduces the topic of COBie for contractors.

While facility managers will gain value from COBie on new facilities, they often express concern for about capturing COBie data collection on their existing building inventory. One 2009 study  demonstrated that as-built COBie data surveys could be easily accomplished. Given management emphasis, the capture of COBie data for an entire campus may be accomplished in 12-14 months simply by modifying service and work orders forms.

Current Status

COBie began in late 2006 under the NIBS Facility Maintenance and Operations Committee. Small grants from NASA and the White House Office of Science and Technology Policy lead, within six months, to a initial specification that considered all available alternatives . As the NIBS Building Information Management (BIM) Council (formerly buildingSMART alliance) was formed, the first demonstration of software meeting the COBie requirements was held less than two years later at the National Academy of Sciences. Since March 2012 COBie has been part of the United States National Building Information Model Standard (NBIMS-US V2). An update to COBie to version 2.4 was balloted  and approved in 2014 NBIMS-US V3.

Today COBie has been included in design and construction contracts in the United States, United Kingdom, and Singapore. There is no telling where it will turn up next since no one has to report their use of open standards! Given the typically slow pace of adoption of new technology in the construction industry, the progress of COBie has been nothing less than meteoric. This is not because COBie is perfect, or that COBie solves all problems related to BIM interoperability. This success is because COBie does one small job, and does it well. COBie delivers information about equipment and spaces at lower cost and higher quality than today's manual (or proprietary) methods.

COBie for Developers

If you are a software developer and want participate in the COBie project, there are several ways for you to engage.

A COBie for construction committee was formed in January 2014 to assist those working in the construction and commissioning markets. For more information on the COBie for construction committee contact Mariangelica Carrasquillo-Mangual of the US Army Engineer Research and Development Center. Since only the leading handful of design software firms have implemented (or begun to implement) management of this group is accomplished directly by the COBie Project Committee.

While COBie began with a small Corps of Engineers project funded by NASA and the White House Office of Science and Technology Policy, COBie version 2.4 (included in NBIMS-US v3) is a national consensus effort. Efforts to make small improvements to COBie are always being discussed by members of the COBie Project Committee.

Relevant Codes and Standards

Templates and Additional Resources


This page contains answers to frequently asked questions about the specifics of COBie. Click the A icon to view the answer to each question. If you have an additional question on COBie, submit through our comment form. Frequently encountered questions will be documented and added this list of FAQ's.

Operational Questions

  1. Is COBie a building model?  

    No, COBie is format for the publication of a subset of a building model. COBie's focus is on delivering building information not geometric modeling. COBie formatted building information is not an entire building model. COBie is a subset of a building model referred to as a "model view."

  2. Do I have to fill out the whole COBie Spreadsheet?  

    The amount of the COBie worksheets to fill in depends on the project stage. Project team members only enter the data for which they are responsible. Designers provide spaces and equipment locations. Builders provide manufacturer information and installed product data. Commissioning agents provide warranties, parts, maintenance information. For more details please see the COBie Means and Methods page.

  3. When do I deliver COBie data?  

    COBie data is delivered along with, or in lieu of, existing contract deliverables depending on your specific contract. COBie does not change the content of existing contract deliverables. COBie does, however, change the format of the information that is delivered. An example specification for the delivery of COBie files may be found here. Delivery of COBie is an information publication activity. The delivery of a COBie data set is not an invitation to share a building model since COBie is simply a set of published building information.

  4. Why is COBie a spreadsheet?  

    Given a large project and progressive owner, there will be sufficient overheads needed to provide a wide range of value-added services that may include the proprietary development of Facility Handover data sets. Most public projects are, however, relative simple, square buildings, completed on a shoestring budget with taxpayer funds. An open exchange format for facility handover data must, therefore, accommodate both the large custom buildings and small public buildings with the least common denominator of technology allowing the widest possible set of project stakeholders. COBie for large projects uses IFC-standard STEP and ifcXML formatted files. Small projects may exchange COBie data, displayed as spreadsheets, and directly update COBie data using these common spreadsheet programs.

  5. How is COBie updated for specific clients?  

    COBie is a standardized format but it's contents are configurable for regional and project practice. The only changes needed are values for columns in the PickList Worksheet. The green columns are client, national, or regional classifications and can be updated. The green coded COBie values are provided as default settings only. PickList Worksheet columns in non-green colors should NOT be changed because they will result in inconsistent use of COBie data by software vendors. For example, the values for 'FloorType' is always one of the three values 'Site', 'Floor', or 'Roof' and coordinates are taken from the 5 values that describe a point, line, or box.

  6. What products and equipment do I include in COBie?  

    All products and equipment listed in design schedules, should be found in the COBie file under the Type and Component Worksheets. Type worksheets identify the category of product. Components are specific instances of each of the Types, typically found in one room. Components must be listed by room. Components that link or span rooms must be listed in each applicable room. Interior doors, for example, should be listed in both spaces that the doors connect.

  7. What software is required to create COBie?  

    The COBie Specification  is a performance specification. This means that it doesn't matter what software is used to create COBie information, as long as the format of the information meets the COBie specification and the content of the COBie file reflects your specific project. Software vendors have begun to directly export to COBie, however, on small projects COBie may also be created or updated by hand directly in the spreadsheet version of the COBie data.

  8. What if my software doesn't support COBie today?  

    Often software that doesn't directly export COBie today will export spreadsheet formatted information in a different order than that provided by COBie. Such information may cut and paste into COBie creating the start of the COBie file without rekeying room and equipment schedules.

  9. Where is the COBie submittal register?  

    The submittal register is held within the Document Worksheet. The set of all documents identified in the designer COBie file as 'Required' can be used to create a submittal register. Use of a web-based submittal register to automatically linked manufacturer documents to building information (models) is essential to the cost-effective implementation of COBie. One web-based submittal register that may be used is the eSubmittal module of ProjNetSM.

  10. How to I check a COBie file?  

    A free program has been created to allow you to directly check a COBie file. This command line program is provided without technical support.

Technical Questions

  1. How many buildings can be exchanged using COBie?  

    Each COBie file should contain a single building. If there are multiple buildings in a given project, each of these buildings should be held it their own COBie worksheet.

  2. Can COBie Spaces contain other Spaces?  

    No. Spaces cannot contain other spaces. Zones should be used instead as super elements that may contain multiple spaces.

  3. What is are COBie Zones?  

    A Zone is a group of spaces that together provide a specific function. A common example of a zone is a group of spaces that the public are allowed to access, and a group of spaces that may only be accessed by employees.

  4. What are COBie Systems?  

    A System is a group of components that work together to provide a specific building service such as ventilation or fire protection. In COBie systems are described by their lowest level. In a two story building, for example, one may describe the HVAC system as two separate systems, '1st Floor HVAC,' and '2nd Floor HVAC.'

  5. What fields are required to be unique within COBie?  

    The first column of each worksheet, called 'Name,' is the unique name for all the rows in that worksheet. Names must avoid unusual punctuation. Using Names, as opposed to row numbers, ensures users' cut-and-pastes across worksheets provide consistent information. For example each worksheet can be prepared from reports produced by disparate applications and then merged into the COBie worksheet. Also character names have been preferred as a miss-typed character is more likely to make a key invalid, whereas a mistyped number is more likely to be a valid but wrong key.

  6. What columns are required in COBie?  

    COBie is color coded. Yellow coded columns are mandatory. These columns must contain a value. If you do not have, or know the value, enter 'n/a' standing for not applicable or not available.

  7. Where can I add properties to COBie?  

    The Attribute worksheet is used to record the attributes of the Components, Types, Systems, Zones and Spaces. One attribute Value record is recorded for a given Attribute Name, SheetName and RowName. Values held for a Type and System can be expected to be overridden by values held against an individual Component. Values held for a Zone can be expected to be overridden by values held against an individual Space.