COBie is an international standard for building data exchange. Its most common use is in product data handover from construction to operations. The COBie specifications and guidelines capture industry knowledge and best practices. The COBie standards do not dictate what information is required for a specific project handover. That responsibility still lies with the owner.
The COBie data model is a subset (“smart filter”) of the buildingSMART data model, more commonly known as IFC (Industry Foundation Classes). Read our article on IFC here. COBie is part of the openBIM movement to collaboratively design, build and operate buildings. It is also part of the UK Building Information Modelling (BIM) Task Group level 2 initiative. The most common representation of COBie is the COBie spreadsheet, but it is important to note that the data format can be represented in multiple ways according to the requirements and needs of the specific data transfer.
COBie is only concerned with the structure and format of the data and COBie templates are only a starting point for defining and fulfilling information exchange requirements. One of the big benefits of COBie is the growing support in both authoring tools and in Computer Aided Facility Management(CAFM) & Computerized Maintenance Management Systems(CMMS).
COBie adoption and interest is on the rise. Even if the basic concepts are quite simple there are still a lot of misunderstandings and uncertainties surrounding its use. In this article we aim to focus on some key areas you need to understand if you are considering using COBie as a requirement or if you are required to provide documentation in a COBie format.
Life before COBie - data transfer problems and solutions
Construction handover has always been a struggle. The information generated this far in the project are only partly relevant for operations. In addition a lot of new documentation needs to be produced and collected for operational needs. The bulk of this work is usually put off until the end of the project when deadlines are looming and budgets are already spent. The information was traditionally provided as paper drawings and documents in binders. The industry has been slowly moving into the digital world and the binders have gotten their CD-ROM and memory stick equivalents. The digitalization has brought the info from the archive room to the file server.
Owners and Facility managers have started using CMMS (Computerized Maintenance Management System) and CAFM (Computer-Aided Facility Management) systems to support their daily task of operating, maintaining and managing the facilities. To do this job they need information about the building and about the equipment in need of maintenance and inspections. The problem in the common scenario is that even if the information is digital it often is locked down in pdf documents. This means that to set up the CAFM/CMMS system the maintenance manager needs to hunt down maintenance schedules and operating instructions and link or copy the data into the system. Hunting down the info is time consuming as you rarely get the info specific to the equipment installed (you get the whole product catalogue and generic instructions as documentation).
To further evolve many professional owners, handover consultant and CAFM vendor have made templates, often spreadsheet based, for capturing data in a more structured way. This requires the contractors to fill in information about the supplier, serial number, maintenance intervals, replacement costs etc. This is a good leap forward as this information now can be imported into the CAFM system of choice. However, every owner, every consultant and every CAFM vendor may have their own form or spreadsheet template. This means that there are new systems for the contractor and subcontractors to learn for every new project and there are no common integration interface for up- and downstream applications. At the start of the project the owner may not even know what CAFM system to use or they have to make a premature decision. These are all issues COBie are trying to address regardless of where in this evolution the owner/ project is at.
Basic principles of COBie
COBie want to be the common industry format that breaks down the barriers listed above. In its current state is is not perfect but it is a natural progression in the ongoing evolution and we see it as a good stepping stone to further evolve digital construction and lifecycle building information management. At its core it aims to replace point solutions and homegrown exchange templates. Below are listed some of the foundational principles of COBie:
Data model : COBie is aligning with the open IFC format (the buildingSMART data model). This means COBie share the industry best practices baked into that data model. This also make integration with design and construction tools and processes easier. In fact technically COBie is a model view definition of the IFC data model the same way as the coordination view is for processes like clash detection.
Format : COBie give users options for different delivery formats. The standard IFC ones are supported and may make sense in many use cases. However COBie also adds specifications and templates for a spreadsheet based data-collection/ delivery. The simple structure of the sheets make participation in an openBIM workflow possible without any specific BIM tool and without knowledge of the IFC data model. The spreadsheet is a “least common denominator” data management tool that contractors and subs already are familiar with. Importers and exporters to various systems and databases also commonly have support for spreadsheet imports.
Classification : Use of a classification system is also a key foundation for COBie. What classification system to use is up to the owner and should be a key part of the requirement when COBie is part of a contract. US-based owners may require Omniclass, UK owners may require Uniclass and a Norwegian owner may prefer Norwegian Standard 3451. Using a classification system adds a dimension in navigating the info and it brings familiarity and aggregation possibilities across projects and owners. Also many CAFM & CMMS systems are using classification systems to structure documentation.
COBie history and adoption
The first versions of the COBie standard was developed by the US Army Corps of Engineers. The pilot standard was released in 2007. In December 2011 it was approved by the US-based National Institute of Building sciences as part of its National Building Information Model (NBIMS-US) standard.
BuildingSMART have been working in parallel with FM handover model view definitions. This work have now “merged” with the NBIMS-US effort and v3 of the COBie standard is a joint effort between buildingSMART international and the National Institute of Building sciences. COBie is also an official buildingSMART IFC MVD with the name “Basic FM Handover View”
COBie has also been picked up by the UK BIM task group and one of the key deliveries for level 2 BIM (The key deliverables are native BIM files, PDF documents & COBie spreadsheets). There is a British Standard specifically dedicated to COBie (BS 1192-4:2014 Collaborative production of information Part 4: Fulfilling employer's information exchange requirements using COBie - Code of practice).
With a list of BIM related British standards (and Publicly Available Specifications) on its way to becoming international/ european standards the adoption and support for COBie is expected to continue its growth.
Alternate COBie representations
COBie is mostly known as a spreadsheet format (excel xlsx or SpreadsheetML XML file). For handover this can also be a compressed zip file containing both the spreadsheet file and PDF documents that are referenced from the spreadsheets.
IFC stp and IFC xml representations - we covered IFC and MVDs (Model View Definitions) here. Basically you have an option to export all the data needed for a COBie handover to an IFC file. The contents of the file is then mostly data and not geometry.
There is also the cobieLite xml format. Still the same data model but using a cleaner xml schema than the spreadsheet-compatible one to focus on ease of use for machine to machine transfer. In this format you skip the visual formatting of the rows and instead of the flat spreadsheet form you get the xml three with nested resources instead of links/references across sheets. However xml is a tree and COBie is really a graph so some relations are described better than others.
The structure of the COBie data model
As a model-view of IFC, COBie share semantics and structure of the buildingSMART data-model. According to COBie the key items to track for facility managers are components (equipment) that needs maintenance/ operation and spaces (rooms) that need management. We will begin to describe the structure by focusing on these key items and their related items in the grey box below.
Grey area - the core
Component - This is the central piece of the asset register. The owner need to keep track of what equipment they have, who made and delivered it, when it needs maintenance, how to inspect it and track history of service requests and work orders etc. The owner needs to specify what items require management and maintenance (and therefore belongs to this list) and what information is needed for each component (and therefore what columns this sheet should have).
Types - The types concept is very important and an often misunderstood concept. Most components are defined by their type (product category). When you install many instances of a common product the common information goes here. So if you deliver 10 similar doors you document what is common information like “manufacturer” and “serial number” on the type description. And then you document the specifics on the component instance, e.g location, installation date, item number etc. This is similar to how BIM tool users would have (Revit) families or (Archicad) GDL objects
Spaces - Spaces in COBie are similar to what we normally would call rooms. However there are some deviations/ additions, e.g. that you may have outside spaces (parking lots, accessible roofs etc). Also you may divide large rooms into multiple spaces where it makes sense from a management point of view. The space are key to COBie for two reasons. In itself space objects are important for space management, tenant management, energy management etc. In addition spaces are important for locating equipment. All equipment should be tagged with the spaces from where you access them for operation/ maintenance. This also mean that all “areas” that define access to maintainable components needs to be on the spaces list.
The rest of the objects in the blue box are mostly grouping or aggregation objects used to classify the other items.
Zones are space groupings. They are quite flexible in use. They can be used to divide the facility into ventilation zones, access zones, rental zones etc. Usually the use of zones are more prevalent after handover. An alternative to using the zone object is classifying spaces either using classification reference or by using custom properties, so you may not even use the zones during design and construction.
Facilities are the buildings themselves. Often there is just one facility in the COBie dataset (similar to only being one building in an IFC export) but there could be more. Important common information like units and phase goes here. Another purpose of this is to have an unique building for this equipment and these spaces to belong to when you merge cobie sheets and import into the CAFM system.
Floors are a part of the building spatial structure and a way to group the spaces. They are important parts of supporting the location and grouping of spaces and equipment so it is important to get right. It is also an important coordination issue if the building is a bit more complex. However please note that it is important to coordinate export, and the levels in the BIM tool not necessarily have a one to one relationship with the building storeys in IFC (and therefore the floors in COBie).
Systems is another way to group equipment. Having a proper system to equipment relation give more intelligence to the FM system. Also the system are maintenance objects themselves and a place to link O&M documentation that are of a more generic kind.
Orange area - Subitems describing the types
The orange square - Job, resource and spare are metadata that defines the components (via their type definition) and are an attempt to collect the unstructured, non-standardized O&M data that normally is found in documents (operating manuals, maintenance guides, spare parts lists etc). This is a good idea and we hope COBie and/or related openBIM standards will evolve into this but currently the support in both the IFC data model and limitation in the spreadsheet format mean that we have seen little examples of good uses of these sheets. We will follow up on this in another blog post.
Green area - the common items
Then on to the green square. They are listed as “common” items. The reason for the common tag is that all of this could be linked to items in (almost) any of the other sheets/lists. E.g. a document is usually linked to a type (e.g. a maintenance manual describing a pump type) but it could also be more generic in nature, e.g describing a system (design of the fresh air system) or being relevant for the whole building (the fire safety plan). The most important sheets/ item types here are contacts and documents (and to a certain extent attributes)
Contacts are people involved in the delivery of products and generators of information. The focus in COBie is much on who filled out the form. Often this is data-generated. The important part in our opinion is who produced, who supplied and who installed the equipment to make sure you know where to go for warranty issues related to production or installation issues. COBie default is to identify these uniquely by their email addresses in the related sheets (e.g. created by person@company.com) and then provide the contact information in the contacts sheet. Again this is an item where we suggest you tailor the delivery requirement to your CAFM or enterprise system as the support in both IFC and COBie is a bit limited for FM use.
Documents are primarily documentation about the delivered equipment. Usually documents are tagged to the types they are related to so that one maintenance instruction describes how to change filter on the 5 similar fans. However there are also a need to tag directly to the instance, for instance for commissioning reports, as built photos etc. Also as mentioned some documents should be tagged to higher level items like systems and facilities.
Attributes are a method to tag custom data to any item type to expand on the properties/ columns that are included in the main sheet. These are similar to the properties (in property-sets) in the IFC data model. We see them as a way for BIMs to export and transfer any custom property data as needed when specific info is needed. However at the present stage you may not need attributes. If the you need some specific info you may as well add a new column in the other sheets. And if you are in need for attribute export you may as well want to export using the step or xml format version of COBie instead of using the spreadsheet. Our experience is that the spreadsheet is not well suited for this but if any of you have other experiences we would love to hear about them in the comments section below.
The remaining items connections and assemblies are similarly questionable, especially in a spreadsheet context. They are attempts to include the more complex parts of the IFC data model into the COBie model view. Again this may make sense in the IFC format especially when exporting as-built data from the services models. However they rarely makes much sense for the services subcontractors trying to use the COBie sheet to specify their deliveries. Again we may be wrong on this one and your experience may be different
We already mentioned classification and a free choice of classification system as a key part of COBie. The important sheets to classify are types (and by proxy items). spaces, systems and facilities. This will help both in organising and finding information inside this facility but also to share information across projects in the portfolio and also to bridge the gap towards the old way of doing things (operations and maintenance information have in many geographies been structured according to classification systems for a long time). At the same time the classification part is giving the global standard a localised twist with the advantages and problems that arise from that. The buildingSMART Data Dictionary (bsDD) part of openBIM has not gotten traction here yet but may be a candidate for further improving COBie. Implementation of the classification will vary a bit based on the format selected. In the COBie spreadsheet the classification value should be filled out in a certain column in the different sheets.The actual classification values are then normally listed in a separate sheet to be used as pick lists in the columns to be classified. Again use of these spreadsheet pick lists may be a signal that some more targeted data management tool is needed.
The different COBie formats - IFC STP, IFC XML, spreadsheetML & COBieLite
Some of the specifics and implementation details of these different formats have already been discussed as part of the data model discussion above. In addition we add some more implementation details to consider when deciding on a format or filling out the form (manually or via export)
Cobie as a spreadsheet - flat structure with references. In the spreadsheet each of the element types gets their own sheet. The column headers describes information to be filled out for each instance and each instance is a row in the sheet-table. There are some challenges to this approach. Formatting of information (e.g. numbers vs strings), preventing typos and setting up correct pick lists. Spreadsheet should not be the authoring tool for large amounts of data. However it is a nice alternative to give subs the ability to take part in the workflow and remove re-entry. Also a host of data management tools support spreadsheet import and export.
COBie as an IFC file (basic handover view). Use of COBie as an IFC file make most sense for exporting data in BIM models from BIM authoring tools. The data is already there is a structured format and the tool have IFC export built in. The only thing new is they have to support the basic FM handover view. The BIM data that is relevant for COBie export has been generated “by” the BIM tool or it has been imported as part of BIM objects supplied by manufacturers. To support the export of data to this standardised format BIM tools usually have ways to set up custom mappings from their native structures (e.g. Revit families) to COBie properties.
COBie as a database. As mentioned COBie information are mostly structured data. Some are generated during design and construction but also a lot is generated/ collected during product install and handover. Neither BIM tools nor spreadsheets provide the optimal features for collecting, verifying and merging this information. For an BIM based workflow all data should be related/ linked to the asset information model but not all information needs to be embedded into the native BIM file or the openBIM model (the openBIM model is data transfer, not a database). Therefore using a distributed database with web-forms, workflow & approvals, change tracking, custom validations, access control etc may make sense. The model will be used for visual support, pre-population of pick lists, pre-population of database items etc. We are building such a tool at Areo as part of our handover management application and expect to see more similar tools in the future that use the COBie interfaces for interoperability and industry best practices.
COBie data drops
We mentioned that the most common use case for COBie is for bridging the gap between construction and operations. A complete COBie should be expected at the time of handover. However COBie also has the concept of data drops. A data drop is an earlier intermediate delivery documenting the state of the project at this stage. These data drops can be used to monitor/ validate this current state and it can be used to start planning how to take ownership and operate the facility. As such requiring and implementing data drops for the major phase changes are enablers of lifecycle BIM. Again the owner needs to be specific of the purpose, contents and delivery time for each drop for it to make sense.
COBie as a requirement
The COBie standards has been developed to be included/ referenced as part of construction, design and product delivery contracts. However it is VERY important to note that just a simple reference to a version of the COBie standard is not enough. We therefore state once again: In addition you need to specify
- what objects require maintenance and therefore should be included in the export
- What classification system to use
- What custom properties to use for each of the items
- If (and how) you want to track relations to the BIM models, e.g ifcGUIDs
- How the delivery process will be (continuous, data drop per phase-change or just as part of the handover)
- How the collection and coordination process will be. Will either the owner or the main contractor hire someone to coordinate the process. (Will it be the BIM manager, Will it be the Architect etc etc)
Also remember :
- Not all data needs to reside in the model, but most of it should be related to the model and all of it should be classified
- Reuse as much as possible of the information in the model. It could be extracted as cobie data and/ or it can be the basis of custom forms/ pick lists and spreadsheet templates
- Information that do not have value in the design and construction could rather be linked to the model instead of embedded in the model. A good database should allow for merging of model data and COBie data.
Summing up
We hope that article has demonstrated that in itself COBie is a simple concept and it is well connected to other openBIM initiatives. It can coexist both with IFC, with native BIM files or it can be used without any "BIM tools" at all. It is also a concept where you can start small and the system can grow with the user/ building owner. It is for both newbuilds and existing facilities.
At the same time COBie is a bit immature as a standard and concept. There are some misunderstandings and there are also room for COBie to grow with the AEC, FM and IT industries. We think COBie is the best we have out there for this need, so we may as well gather our initiatives around helping improve and clear up misunderstandings instead of complaining and making new standards.
COBie and related topics will be a returning theme on this blog. If you have experiences or want us to cover certain topics, please share by commenting below. If you find the article helpful please help us spread the message by sharing via the social media links given below.
