What is BIM

BIM (Building Information Modelling) is a term continually thrown around in the industry today. Unfortunately, few sources clearly identify what it is. Sometimes doing the opposite and pigeon-hole it into such a narrow scope; few projects can go down that road. We also often read (and I have sometimes said), “BIM has different meanings to each person you speak too”.

I actually don’t think it’s that complicated. Most BIM “experts” would be happy to agree with the following simple approach: “BIM is a process involving building data management, with a level of spatial understanding”. However, stakeholders may have very different expectations of BIM outcomes or deliverables.  This is nothing new! Building owners, Architects, Engineers or Contractors will view a building very differently. Thus; why should BIM outcomes or deliverables be any different?

So let us focus back on just BIM? BIM outcomes are another discussion. The below statement is my current approach and is a manipulation of the Wikipedia overview (May 2013). 

My BIM Definition:
Building Information Modelling (BIM) is a managed process, involving the recording, exchange, and application of pre-defined, trusted, structured digital data; representing physical, functional and spatial characteristics of a facility.

Let’s look at some of the keywords within:

Managed Process: 
Implies a planned (documented steps) set of supervised actions occurring with a specific end goal. Process Mapping becomes an integral aspect of BIM and is created to roadmap each outcome.

                      Above Image extract from Penn State BIM Execution Plan

The goal of the process cannot be overstated. Without a goal, there is no point in BIM. This makes a mockery of projects where a client just asks for “BIM” on their project.

Data Recording: 
During the production of any product, a substantial amount of information is generated and collected. The benefit of recording all relevant information to one place (single entry) and populate multiple outputs is the first principle of BIM.

Data Exchange: 
At the core of BIM lies the transfer and sharing of reliable data with minimal degradation.  BIM has many Information Exchanges, including COBie (Construction Operations Building Information Exchange) and IFC (Industry Foundation Classes), just to mention a few. The basis of any information exchange is to maintain data fidelity when transferred between parties or software applications. This information exchange requires careful management.

Above:  Information transfer between parties. Source: BIM Handbook: A Guide to Building Information Modelling for Owners, Managers, Designers, Engineers and Contractors. Authors: Chuck Eastman, Paul Teicholz, Rafael Sacks & Kathleen Liston.

That is, the generated / exchanged data has a specific use and purpose.

In order for any process to truly work the parties involved need to understand exactly what data is generated, by whom, when is it exchanged, how it can be used, does it require maintaining and if so my whom. BIM Management Plans, Level of Development tables and other matrixes may be used to map these out.

Trust between parties is one of the cultural difficulties very evident in the building industry. Yet, for BIM to work, trust is an integral part. So how do we develop trusted data?
It relies on open, quality control, i.e., the recipient of the data can clearly see how the data author is checking and maintaining the information.

An example of this as part of a deliverable is within the COBie 2 specification: Section 1.1.4 Clause “C”:              The contractor shall check all COBie2 files prior to submission, regardless of the source of those files.  The Contractor shall submit a brief report with each COBie2 deliverable indicating steps taken to verify compliance with the COBie2 format.

Structured Digital Data: 
We have been exchanging digital data about buildings since computers came into the office. However it is rarely truly structured, i.e. the naming, formatting, and generation is defined and thus consistent.

A building information model is a virtual prototype of a building at a specific time during its lifecycle. It is an accurate representation of the building, within its fit for purpose.

Elements in a building information model are to be object orientated, and thus have rules on how they perform in the built environment. This may be as simple as doors understanding they can only be hosted in a wall, to windows containing detailed thermal properties, allowing for heating analysis.

Every element within the BIM (model) must have some spatial awareness or geometric coordinate. I.e. understanding what space/rooms it’s in (e.g. a COBie workbook) or an x,y,z and orientation coordinate (e.g. code checking model).

The concepts of BIM are not restricted to buildings, but can be extended to anything in the built environment. This may include, but not limited to;  buildings, structures, bridges, roads and infrastructure etc.

Some changes to the definition over time:
As we are not within the Science realm, the exact wording of definitions develops over time. There are some obvious wordings which are now left out from current BIM definitions:

Entire Lifecycle: 
In some past definitions, the word whole Lifecycle was used. In reality, there are few buildings were BIM is engaged from pre-planning, design, construction, re-development, decommissioning and disposal. It will take about 45 years before anyone can say they have achieved this. What is also missed, a BIM could be used after demolition, for future planning. BIM occurs during a part of the lifecycle but does not need to include all of it. There is also an emerging philosophy which state “Control Cycle” is really the goal is: Refer to Unified Theory of BIM – Bill East – Youtube:

In many cases, a 3-Dimensional Model is just a by-product, or a part of the journey to develop an initial BIM data. A MS Excel workbook (e.g. COBie data) containing component data and their spatial location can be considered a BIM.

Little BIM: 
If we remove any of the key words from the above definition, the result is often referred to as Little BIM. Little BIM may not be as flashy, but is a vital step for firms building systems to provide a BIM service. I would be as bold to say; “if you can’t do little BIM well, you will not be able to deliver (Big) BIM”. Little BIM can be seen as a method to improve QA, efficiencies, communication and coordination.

As BIM is fundamentally a process, any BIM deliverables taken on board, result in business and workflow change. Nobody wants a micromanaged project, thus team familiarity to Little BIM, before Big BIM deliverables is essential.

COBie and Autodesk Revit

Recently you may have seen Autodesk Revit did well out of the “Software for Design” or Model Authoring applications within the 2013 COBie Challenge. It is still not perfect, but it is a great development forward from earlier COBie exporters. I’ve put down some of my findings and thoughts on the items which are of interest.

The below article discusses the data generation and augmentation for the building “Design Stage” (Design Submissions). The COBie process includes the following information gathering stages:

Owner’s Criteria
(Programming / Pre-Design Stage) Building Owner
Design Submissions
(Design Stage) Design Team
Electronic Submittals
(Contractor Mobilisation - Shop drawings and product sign-off) Main Contractor and Sub-Contractors
Equipment Installation
(Construction) Main Contractor and Sub-Contractors
Equipment Start-up
Commissioning Agent / Main Contractor / Sub-Contractors
Commissioning Agent / Main Contractor / Sub-Contractors
(Practical Completion & Defects) Commissioning Agent / Main Contractor / Sub-Contractors
Building Handover
Project closeout. The transfer of ownership of the project from contractor to building owner (Effects: OH&S, reliability, standards of operation, maintenance, and operational costs)

Figure 0.0 – Simplified COBie relation to Design Models

Project Phases
COBie Worksheet
Schematic Design
Design Development
Construction Documentation









Figure 0.1 – Sample COBie Data Requirements per Project Stage (source – BIM for Facility Managers – Wiley – Edited by Paul Teicholz)

The New Revit COBie Toolkit (2013CC):
NOTE: the COBie 2.4 compliant exporter (COBie Toolkit – Autodesk Consulting) which partook in the 2013 COBie Challenge (2013CC) is not yet publically available. This version of the Toolkit is far superior to the existing release, whose format has not changed over the past years.

I believe the updated exporter 2013CC Toolkit will be available soon (subject to Autodesk’s discretion).  It includes massive innovations to export directly to a new or existing COBie Microsoft Excel (.xls) spreadsheet and populate the: Contact, Facility, Floor, Space, Zone, Type, Component, System, Attribute & Coordinate worksheets. It also allows for custom COBie Category, i.e. a Classification System, such as Onmi-Class or UniClass 2 etc. More information on COBie 2.4 toolkit here:

NOTE: COBie classification name combines Class Number and Class Title. This allows the reader to search by everyday names as well as having the directory numbering system.

The Toolkit was presented at Autodesk University 2012. More information here:
All information within this article about 2013CC is from publically available sources or Autodesk University Class handouts.

The COBie Challenge is a very important bSa (building Smart alliance) application test, which truly acknowledges a software vendor's interest in being part of the solution, and not just “another software” adding to the problem. The COBie specification is the only proven, thoroughly documented, open standard format for using a BIM to generate the initial data for Building Asset Management.
NOTE: There are several methods of exporting COBie data out of Revit. The COBie Revit Toolkit is one of the most direct and straightforward workflows. Other methods include but are not limited to:
Exporting Schedules directly out of Revit to .txt to Excel – Similar the original Revit COBie Toolkit, with reduced functionality

Managed Assets:
Before we go any further we need to get a general idea of what are Managed Assets, as these are the items we populate into the COBie Workbook.

Managed assets are those assets which;
  • requires management
  • requires (considerable) on-going maintenance
  • has consumable parts requires regular periodic inspections

The exact extent of these will vary from buildings to buildings. Below is a general list of assets from the COBie Guide

Required HVAC System Assets
Air Handling Units
Fan coil units
Variable Air Volume boxes

Required Plumbing System Assets
Water treatment Assemblies
Plumbing Fixtures

Required Fire Suppression System Assets
Sprinkler heads
Fire extinguishers

Required Electrical System Assets
Light fixtures
Distribution panel
Required Control System Assets               

Required Elevator System Assets

Required Food Service System Assets
Waste Disposer

Required Architectural Assets
Furnishing Assets
Site Assets
Site Water Distribution System
Site Fire Suppression System
Water Supply Wells
Site Sanitary Sewer
Fuel Distribution

From the above, you can see Managed Assets are often from the Architectural and Building Services fraternity. In a typical facility, the structure is expected to exceed the lifespan of the building. That, however, is not saying structural elements will never be managed assets. Exposed structure, moving structures and earthquake sacrificial “steel fuses” may need periodic inspections and maintenance. Generalized building maintenance (applicable to all buildings) which requires minimum skills and easily available tool/equipment resources may not be included within COBie (e.g. Rainwater gutters inspected and cleaned every six months, Windows cleaned every 12 months etc.). COBie’s primary function is to replace the traditional Facility Handover documentation. This may be expanded by the Building Owner.

Understanding COBie:
If you are new to COBie I would suggest starting at Bill East’s COBie College on Youtube:

COBie Summary: COBie is a specification used to deliver useful facility information by streamlining planning, design, construction, and commissioning activities. (Bill East)
COBie’s official name is Facility Management Handover (FM) Model View Definition (MVD).

Below are some extracts from the COBie Guide

COBie does not add new requirement to contracts, it simply changes the format of existing deliverables from paper documents and proprietary formats, to an open, international standard format.
Since COBie is an extract from the Construction Documents Design deliverables, the information in COBie should be a perfect match for the print on the drawings from the deliverables.
Information found in a COBie file shall accurately reflect the associated information on the design and as-built drawings schedule at that stage of the project.
Regardless of the source of the properties specified in client contracts, COBie.Attributes for all COBie.Type and COBie.Component records shall match the properties found on equivalent design drawing equipment and product schedules.

COBie Naming is also very particular. There is a recommended naming convention for items which may be a slight deviation from traditional documentation methods.

Naming: All Managed spaces, products and equipment found on design schedules and drawings shall be uniquely named.
During design, the Architect shall be responsible to resolve all conflicts in duplicative naming by their own staff and all consulting engineers.
Space Naming: COBie.Space.Name’s shall exactly match the space names shown in the related design and construction deliverables.
Type Naming: The name of each COBie.Type of product and equipment shall begin with a signifier of the product type that would be recognizable to a facility manager outside the context of the specific design. For example, the designation “DOOR-A” uniquely distinguishes that COBie.Type from the light fixture type “LIGHT-A”.
Component Naming: items where design schedules describe only the asset types, such lighting of plumbing fixture schedules, the following formula for creating a unique component name shall be used.
COBie.Type.Name & “-“ & COBie.Space.Name & “-“ & Item Count in Space.
For example, if there were two sinks of type “Sink-A” in space “100” the unique names of each of these components following the algorithm shall be “Sink-A-100-01” and “Sink-A-100-02”.

Component Spatial Containment
All COBie.Component records shall be identified in the COBie.Space in which the asset is found or the COBie.Space from which the asset is operated.

Revit General:
The good thing with a COBie approach, if Revit best practices are followed, the model author is half way to generating a usable Revit file. Items to adhere to:

Documentation matching the Model: All items called up in the documentation (drawings, schedules and possibly specifications) related to COBie.Spaces, COBie.Types and COBie. The component must match exactly the data in the model.

Avoid In-place Families: In-place families in Revit will not schedule to a “Level – (COBie Floor)”. Nor will they report a Classification, if the system parameter Onmi-Class is in use. I would suggest not using in-place families for any of the identified managed assets.

Unit Rounding: We often need different outputs of units. An item to be aware of when exporting with limited decimal places can lead to undesirable outcomes. An example, in exporting a cladding panel of 0.45m² to square meters with zero decimal places, results in a panel of 0m².

Use Systems: In order to populate the COBie.Systems worksheets, model authors for Building Services must establish and use Revit Systems appropriately.

Rooms and Spaces: All models will need to use Rooms or Spaces, in order to report the spatial location of equipment. Spaces are named and numbered directly from the Architectural model containing rooms using the Revit MEP space naming utility or a similar API. In the event the Architect has multiple models, the model containing Managed Assets must also contain Rooms.

I will expand on this area as we progress through the article.

Model Accuracy: COBie is all about data. For spatial accuracy, COBie primarily is to allow the user to identify what Space (Room) a managed asset resides. Thus, tolerances of ± 250mm are satisfactory. This also opens items up a bit and allows the component information author to host the component in their model. From the COBie Guide: The general rule to interpreting drawing inconsistencies is that the more detailed information governs over less detailed information. 
That is: the model with the greater information on the COBie Component, is the model which is used to export the component data to COBie.

Data Entry: On a COBie delivery project, it would not be very efficient to add all the COBie “design data” directly in Revit. A Revit to Microsoft Excel to Revit plug-in tool will help with data entry, data manipulation, and data checking. This method may also be a simple solution for one party to adding data to another party’s model. When using such a tool, it will involve a large amount of data exchange between Revit and Excel; thus, make sure the product of choice is robust and an established application.
On larger projects, an FF&E (Furniture, Fixtures and Equipment) / RDS (Room Data Sheet) data management tools are likely to be engaged. Examples: dRofus, CodeBook or similar application.

COBie Work Book:
The COBie Work Book is broken down into several Worksheets. Further information on the Worksheets are found in the COBie Contract Specification V1.1 – Dec 2009 here
Any below comments is using Autodesk Revit 2013. Future and past releases of Autodesk Revit may have different outcomes.

COBie.Contacts Worksheet:
It may be determined, COBie Contact data does not need to reside within the BIM. The data could be held in a separate linked database or entered manually into the COBie worksheet as they arise. However having the Contacts within the BIM allows COBie.Types to be more easily associated with the relevant element Types. At a design stage this will include the contact details for the person: validating the data (CreatedBy), and any component suppliers or manufacturers (COBie.Type.Manufacturer).

Figure 1.0 – COBie.Contacts worksheet

The 2013CC Revit COBie Toolkit includes an inbuilt Contacts section which can be attributed to the COBie.Type.CreatedBy parameter. At the time of writing, these pre-entered contacts cannot be called up in a Type schedule to attribute to the “COBie.Type.Manufacturer” column.

Figure 1.1 Contact Attribute assigned to COBie.Type.CreatedBy parameter - 2013CC Revit COBie Toolkit

Figure 1.2 COBie.Contact information which is exported to the Contact worksheet - 2013CC Revit COBie Toolkit

Authoring Source:  The Contacts worksheet requires participation from all parties. Attributing the contact Information beyond the associated “CreatedBy” attribute is the responsibility of the party entering COBie.Type data. Refer below to the COBie.Type Worksheet.

COBie.Facility Worksheet:
The Facility worksheet will always be a single row entry as each facility building requires its own COBie workbook.

Figure 2.0 – COBie.Facility worksheet example

Most of the data in the Facilities worksheet is provided by the building owner. It is common multiple models are used to generate a COBie workbook, thus the COBie.Facility worksheet “external reference” (purple cells populated by the authoring software) columns may not be populated.
The 2013CC Revit COBie Toolkit includes a section to make sure all units are exported correctly:

Figure 2.1 - Units export settings - 2013CC Revit COBie Toolkit

Note: Under Currency if “Dollars (USD)” are selected, the published value is just “Dollars”.
The Linear, Area, Volume and Currency units are exported.  These settings allow the overriding of existing units in the model to the COBie Excel file.
Authoring Source:  I would suggest any modification or addition of data in the COBie.Facility Worksheet during the design stage, come from the Architectural discipline / model.

COBie.Floor Worksheet:
The floor worksheets in COBie, are similar to Revit Levels. COBie uses floors (Revit levels) to locate Rooms and Components (similar to the Level Building Story instance On/Off parameter). Secondary datums are irrelevant (i.e. Ceiling Levels, Parapet Levels and Structural Levels). 

Figure 3.0 - COBie.Floor worksheet example

In classifying floors COBie uses the following:
“Site” (a general level allocated to the site elements, including courtyard spaces etc. NOTE: on campus style developments, the “Site” may be considered a separate facility and thus have its own COBie Workbook)
“Floor” (All usable building floors)
“Roof” (All roofs/canopies which require maintenance including Roof Plant Areas)

In the event, the building has split levels a separate Revit level may be created for each split floor level. For a room naming convention consider using a suffix to identify the split level (e.g. Level 1A, Level 1B).
NOTE: None of the above items will detract from the current common practice of having a separate Building and Site Revit model, to help on site and project requirements. See post here:

All the Revit COBie export tools will export all the levels modeled in Revit, whether they are relevant or not. Thus, you may need to cull irrelevant levels from the exported spreadsheet if they are not applicable.

Consistency across Models: It is vital when using COBie, names are consistent across models and documents. Thus, the Level names in the Building Service models must match “exactly” what the Architectural Model levels names are. Using the Revit Copy/Monitor tool will not only ensure the building services model level elevations are synchronized with the Architectural model but also the Level Names.

COBie.Floor Worksheet Column Headers:
This is the height of the Floor above or below the primary building Entry Level. Revit 2013 cannot schedule levels (Revit 2014 can now schedule Levels). Following the best practice for when starting a new building project; make sure the Main Entry Level has the project elevation of “0.0” (On reporting ADH (Australian Height Datum) levels, a type of “Survey Point” Base Elevation is engaged). Within COBie “Elevation”, a level type of “Project Base Point” Base Elevation is used. The 2013CC Revit COBie Toolkit will report to the reporting value of the levels.

COBie.Floor.Height: The distance measured from the associated Floor to the Floor or Roof above, and thus will provide a Floor volume calculation. This is irrelevant for the Site and Roof Levels (as there is no height limitation, and thus filled out ‘n/a’. The 2013CC Revit COBie Toolkit automatically calculates this value by measuring the distance to the next modeled upper level. This value may be incorrect and need checking upon export.

Figure 3.1- Typical General Arrangement Building Section showing required COBie Elevation and Height

Authoring Source:  I would suggest any modification or addition of data in the COBie.Floor Worksheet during the stage, come from the Architectural discipline / model.

COBie.Spaces Worksheet:
A COBie Space is very similar to a Revit Architecture Room or a Revit MEP Space. However, a COBie Space also includes any floor or ceiling voids. Thus, a COBie space is hosted on the relative Revit Level, and includes a height from the top of the Structural Slab, up to the underside of the Structure above (i.e. the total usable height).

Figure 4.0 - COBie.Space worksheet example

COBie.Space.Name: This is a primary key and thus is unique. The COBie.Space.Name is equal to a Revit Room Number, and thus with Revit rules any duplicates are notified to the operator. Room Numbering is an item which requires careful consideration and is a whole topic in itself. It should at a minimum include the level number as a suffix.

COBie.Space.Category: This is the room allocation classification. It can use Omni-Class, UniClass 2 or any Building Owner established classification system. This is not an “Out of the Box” Revit parameter. The 2013CC Revit COBie Toolkit includes a tool to help with this task (AC Classification Tool).

Figure 4.1 – Element Classification tool - 2013CC Revit COBie Toolkit

In the previous form of the Revit toolkit, a Room Key Schedule (pre-populated with the Classification Names) was used. I would hope in a future version of Revit a System Room Classification parameter will evolve.

COBie.Space.Description: This is the Revit Room Name. It is a way people can understand the function or operation of the room.

COBie.Space.RoomTag: In many circumstances the Room Numbers identified by the Architect, are not how the building operator will want to number them. The final building operator’s door sign room numbers are identified in the RoomTag. This data is added to the spreadsheet by the Builder (nearing the completion of the building) or the building owner themselves.

COBie.Space.UsableHeight: - Total height (from base slab without flooring to ceiling without suspended ceiling) for this space (measured from top of slab below, to bottom of slab above). To be provided only if a space has a constant height. The 2013CC Revit COBie Toolkit will use the “Unbound Height” Room Parameter. The Unbound Height is the sum of the Room Base Offset, plus the Limit Offset parameters.

COBie.Space.GrossArea: - Sum of all floor areas covered by a space. It includes the area covered by elements inside a space (columns, inner walls, etc.) and excludes the area covered by wall claddings. NOTE: The client may decide a different method to measure the Space Gross Area. This is identified in the COBie.Facility.AreaMeasurement column. The 2013CC Revit COBie Toolkit will use the Room computation area settings as per the Revit area settings. Thus use due care when exporting this value.

COBie.Space.NetArea: - Sum of all usable floor areas covered by the space. It excludes the area covered by elements inside the space (columns, inner walls, built-in's etc.), slab openings, or other protruding elements. Varying heights are not taken into account (i.e. no reduction for areas under a minimum headroom). NOTE: The client may decide a different method to measure the Space Net Area. This is identified in the COBie.Facility.AreaMeasurement column. The 2013CC Revit COBie Toolkit will use the Room computation area settings, as per the Revit Area settings (Same as COBieSpace.GrossArea). Thus use due care when exporting this value.

MEP Spaces: As mentioned above, all MEP models will need spaces to report Component locations. The Revit MEP Space naming utility will replicate (and update when run) MEP Space Names and Numbers to match the Architectural Room Name and Numbers. COBie.Zones.SpaceNames and COBie.Component.Space report the Space Number for components and zones exported out of a Revit services model.
In order to make sure all MEP spaces match the architectural model, I would recommend a check Space / Room schedule are created per level to include a total room count.

Figure 4.2 – Revit MEP Space Naming Utility – available from the Autodesk Subscription Website

NOTE: If the Architect is scheduling managed assets across linked files, Revit considers Rooms and Spaces as separate schedule items. Thus, items placed in a space will only schedule to a space. In order to create a Room Equipment List across the models, all models will need Rooms of the same Number. Unfortunately, this requires some workarounds but is achievable (In the Architectural model, group all the rooms. Save as a project file. Link new Room Group file into Services model and bind).

Authoring Source:  I would suggest any modification or addition of data in the COBie.Space Worksheet during the design stage, come from the Architectural discipline / model.

COBie.Zone Worksheet:
There is no direct equal in Revit to a COBie Zone, however, it is very similar to grouping several rooms together under a department parameter. Specific parameters are created for Rooms/Zones.

Typical COBie zones include:
Circulation Zone / Departments
Generated by the Architectural model rooms
Fire Alarm Zone
Generated by the Fire Services model zones
Historical Preservation Zone
Generated by the Architectural model rooms
Lighting Zone   
Generated by the Electrical model spaces
Occupancy Zone
Generated by the Architectural model rooms
Ventilation Zone
Generated by the Mechanical model spaces

Figure 5.0 - COBie.Zone worksheet example

Exporters have different ways to achieve spaces. I like to keep it simple and personally, export it manually from a Room/Space schedule.
Authoring Source:  This data is generated by multiple parties at the design stage. Refer to examples above.

COBie.Type Worksheet:
The COBie 2.4 Type worksheet has added several new column headers to the right of the spreadsheet:
U             Nominal Length
V             Nominal Width
W            Nominal Height
X             Model Reference
Y              Shape
Z              Size
AA          Color
AB          Finish
AC          Grade
AD          Material
AE           Constituents
AF           Features
AG          Accessibility Performance
AH          Code Performance
AI            Sustainability Performance

These items are now including specification information including performance items, finishes etc.

Figure 6.0 - COBie.Type worksheet example

A Revit schedule may be created for this in the project for data checking and modifying, and may be used for direct exporting.

COBie.Type.Nane: This value is a “Primary Key” (Unique across the entire project). The COBie Guide also has some recommendations for its naming conventions:

Type Naming: The name of each COBie.Type of product and equipment shall begin with a signifier of the product type that would be recognizable to a facility manager outside the context of the specific design. For example, the designation “DOOR-A” uniquely distinguishes that COBie.Type from the light fixture type “LIGHT-A”.

I would suggest an agreed Type abbreviation naming system is deployed here using 2 to 5 letter abbreviations (e.g. AHU-1 – Air Handling Unit Type 1 etc.). It should be short as it will appear as part of all the Component names. I have come across references to using the US National CAD Standard version 3.1 to Type abbreviations, however, this may not meet Australian requirements.
There are many columns the COBie.Type workbook which may not be added to at design stage. However, if the information is available, it should be added.
The task of identifying the exact Family Types which are exported can be very time-consuming. The new 2013CC Revit COBie Toolkit has a specific tool to assist in this.

Figure 6.1 – Selection of Family Types to export-2013CC Revit COBie Toolkit

Authoring Source:  The party generating some of the COBie.Type data may change during the project (In early design the Architect may add items as a placeholder. Later the service engineers may take responsibility for these items). Each design disciplines are allocated a specific classification of elements for data generation. An Element Authoring Matrix will assist in defining responsibility. The discipline with the greater amount of specific Component data are allocated its entire COBie responsibility. Most building service elements are populated by the building service discipline, as they will also generate the COBie.System data.

COBie.Component Worksheet:
This is an instance list (schedule) which includes the room the component resides. The Green columns to the right are generally entered during the construction stage.

Figure 7.0 - COBie.Component worksheet example

COBie.Component.Nane: This value is a “Primary Key” (Unique across the entire project). The COBie Guide also has some recommendations for its naming convention:

Component Naming: items where design schedules describe only the asset types, such as lighting of plumbing fixture schedules, the following formula for creating a unique component name shall be used.
COBie.Type.Name & “-“ & COBie.Space.Name & “-“ & Item Count in Space.
For example, if there were two sinks of type “Sink-A” in space “100” the unique names of each of these components following the algorithm shall be “Sink-A-100-01” and “Sink-A-100-02”.

The Revit “Mark” parameter is engaged here. I would strongly recommend a Revit to Excel to Revit application to automatically populate this value. This unique name is required to appear across all construction documentation. This maybe a change from traditional documentation practices.

COBie.Component.Space: The Revit Room Number the component resides. Doors or windows called up must list the “ToRoom” and “FromRoom” within the same cell.

COBie.Component.Description: Identifies if the component is a “Fixed” or “Movable” element.
Authoring Source:  See COBie.Type Worksheet -  Authoring Source.

COBie.System Worksheet:
Buildings contain groups of components that, when connected, provide specific required services.  The COBie.System worksheet is designed to identify the components that make up a given system.   In general, systems shall be identified by building service, floor and wing. The names of systems within each system type shall be approved by the owner.

Typical COBie Systems may include:
Fire Protection                                 (Revit Piping Systems)
HVAC Service                                  (Revit Duct Systems)
Plumbing Service                            (Revit Piping Systems)
Electrical Service                             (Revit Electrical Systems & Revit Switch Systems)

On a typical building, these are broken down into sub-systems for the localized areas they are covering, e.g.; Floors or Building Wings.

Figure 8.0 - COBie.System worksheet example

COBie.Systems.Name: This value is a “Primary Key” (Unique across the entire project) of the System name. 

COBie.System.ComponentName: Lists all managed assets (Component Name) within the system.

Figure 8.1 – Selection of Systems to export-2013CC Revit COBie Toolkit

Figure 8.2 – Selection of Duct Systems to export - 2013CC Revit COBie Toolkit

From the above dialogue, Revit Systems for exporting are selected.

Authoring Source:  Generation of each system will be from the relevant services consultant.

COBie.Document Worksheet:

COBie Documents may include the following electronic submittal documents:
Preconstruction Submittals
Shop Drawings
Product Data
Samples literature
Design Data
Test Reports
Manufacturer Instructions
Manufacturer Field Reports
Operation and Maintenance
Closeout Submittals
Design Review Comments
Specifications / Schedules
Request for Information
Client Requirements
Contract Specifications
Contract Drawings
Contract Modifications
Punch List Items (Defects Lists)

At design stage (Contract Documentation), the COBie Documents ay include contract drawings, schedules, and specifications.

Figure 9.0 - COBie.Document worksheet example

The design team may decide not to use Revit to manage the COBie Documents and add the data directly to the spreadsheet. At the time of writing the Author was not aware of any Revit plug-ins directly designed to manage the COBie.Documents worksheet.

Authoring Source:  The Document worksheet requires input from all COBie contributing parties.

COBie.Attribute Worksheet:
The minimum set of properties required for all type worksheet rows shall be the properties found in the Specifiers’ Properties information exchange (SPie) specification.

Figure 10.0 - COBie.Document worksheet example

In Australia, there are limited products which contain SPie data sheets. “The COBie Guide” has a list of recommended attributes for typically managed assets.

Typical Unit
(as identified in client’s contract)
Water Flow
Ambient Temp
Pressure Drop
Entering Water Temp
Leaving Water Temp
Motor Controller
Unloading Steps
Chiller Media
Chiller Type
Refrigerant Type
Energy Efficiency Ratio (EER)
Btu/hr to kW
Integrated Part-Load Value (IPLV)
Heat Reclaim
(from approved list of placement types)
(If found on drawing schedules)
(If found on drawing schedules)
(If found on drawing schedules)

Table 10.01 – Sample extract from “The COBie Guide” – Chiller - Table 4 Design – Minimum Chiller Schedule Headings

Typical Unit
(as identified in client’s contract)
(Space Name)
Ceiling Type
Ceiling Finish
Ceiling Height
(from approved list of placement types)
(If found on drawing schedules)
(If found on drawing schedules)
(If found on drawing schedules)

Table 10.02 – Sample extract from “The COBie Guide” – Finishes - Table 35 Design – Minimum Finish Schedule Headings

Manually populating a COBie.Attributes worksheet is very labor intensive, and there is no Revit out of the box method to transpose the data into the appropriate format. The 2013CC Revit COBie Toolkit does a very good job at this. The preferred units and exact parameters to export are specified.

Figure 10.1 – Setting on Attribute units -2013CC Revit COBie Toolkit

Figure 10.2 – Parameters to Export - 2013CC Revit COBie Toolkit

Authoring Source:  See COBie.Type Worksheet -  Authoring Source.

COBie.Coordinate Worksheet
The Coordinate worksheet identifies an X,Y,Z for Components and the coordinates of Spaces and Floors. This worksheet is an optional client deliverable, and would only be requested if the building owners FM system (CAFM – Computer Aided Facility Management) can integrate component / space coordinates. The 2013CC Revit COBie Toolkit will export and populate the COBie.Coordinate worksheet.

Figure 11.0 - COBie.Coordinates worksheet example

Figure 11.1 – Coordinates Export - 2013CC Revit COBie Toolkit
Authoring Source:  See COBie.Type Worksheet -  Authoring Source.

Other COBie Worksheets:
Assembly, Connection, Impact & Issue worksheets are all optional building owner deliverables. At the time of writing, there is no known software application with integrates the automatic generation of these worksheets.
Spare, Resource & Job worksheets are populated by the building commissioning agent during the commissioning stage.

Autodesk Revit is one of the best-positioned applications in generating design stage COBie data. The new Autodesk Consulting 2013 COBie Challenge Revit COBie Toolkit goes a long way in generating the majority of the data. There still are improvements to be made. It appears Autodesk are committed to the future growth and development of such tools. Features I would like to see in the future may include:
  • Save export settings to an XML template file
  • Ability to create custom parameter mapping for all worksheets
  • Ability to assign contacts to the COBie.Type.Manufacturer and other COBie.Type contacts
  • Ability to export link file data would be helpful

I believe the big challenge to designers in efficiently delivering COBie data, is down to data entry efficiencies. For many designers, this would be a manual process and there quickly becomes the realization, there is considerable double entry of data between models/schedules and specifications within a project, and more again across projects. There quickly becomes a need to have a central Product library database, which can then automatically populate project models, schedule, and specification information.

Figure 12.0 – Product data entry workflow.

A key aspect of the above Product Library Central Data Base are product Classification Systems (such as Omni-Class). This will streamline mapping products to the model, and data entry from SPie (Specifiers’ Properties information exchange) cut sheets.

References: Text in grey.

The author uses all means available to make sure the integrity of the facts presented. In the event any items are incorrect or misleading, please contact and notify the author.