COBie: UNDERSTANDING COBie
COBie stands for “Construction (to) Operations Building information exchange” and is used to capture essential project data for facilities and asset management. It was developed for the United States Army Corps of Engineers in 2007, becoming a UK standard (a “subset of BS ISO 16739 IFC documented as a buildingSMART model view definition (MVD) which includes operational information”) for BIM Level 2 delivery in 2014.
According to COBie’s author, Bill East, it answers three questions:
- What rooms and equipment are delivered in a building?
- Where does a technician go to work on that equipment?
- How is the equipment operated and maintained?”
PAS1192-2 and BS1192-4 expand the requirements of using COBie for maintenance handover only to its inclusion as part of the ongoing information exchanges alongside native model formats and PDF.
While COBie can exist in multiple formats (spreadsheet, STEP physical file format, STEP XML format, and COBie lite transactional XML format) it is most likely to encounter COBie as an Excel spreadsheet.
To understand how COBie is formatted and what each worksheet covers, it is helpful to refer to the National BIM Standard United States version 3.0 part 4.2 “Construction Operation Building information exchange (COBie) – Version 2.4” section 220.127.116.11.2 on page 27. This lists definitions for the contents of each of the 20 worksheets and fields:
When referring to a COBie value, the convention Sheet.Column is typically used.
e.g. Space.Name refers to the Name column in the Space sheet.
Start with the Instruction page (which doesn’t contain instructions, but a summary of the completed COBie data). For UK BIM Level 2, the format of COBie should be 2.4 based on IFC 2x3:
The Legend at the bottom of this sheet explains how the colour coding works throughout the spreadsheet.
Required Self-explanatory. These fields must be completed.
Reference to other… A look-up list to another part of the COBie data. For example, Component.TypeName refers to all the entries in the Type.Name column.
External reference A value that is typically filled in by software when generating COBie. This usually refers to the ExtSystem, ExtObject and ExtIdentifier columns.BS1192-4 allows for these to be filled in “if available”.
If specified… “Optional” columns. Often these refer to columns where the data may not be available until handover, such as SerialNumber, or most of the Impact sheet. In these instances it is necessary to refer to the EIR to clarify expectations.
Secondary information… This is not explained, but can be presumed to refer to the headings of columns.
CONTACT & Facility
The Contact sheet should be a list of all people involved in the production of the data and referenced in the other worksheets. This can refer to individuals or use generic company details, which should be specified in the EIR.
The Facility is the building, or section of infrastructure, to which the COBie data relates. How the facilities are defined will be specific to the project, but would typically be defined by the EIR, the contract or the BEP. In terms of IFC, this would usually be expected to map to the IfcBuilding entity.
For any entry in COBie, the procedure for producing correct output is simple:
- Identify the field
- Look up the definition in NBIMS Information Exchange section 18.104.22.168.2
- Work out what property you should use from your authoring tool
- Make sure the value of that property is used
To better understand this procedure, and how COBie data can be completed, an example of completing a Component entry can be used.
What is a Component? The NBIMS Information Exchange document describes it as “individual instances of the products”. In building terms it is an item of equipment, or a physical object. Light fittings, doors, furniture, piping, valves would all be examples of components.
The first column to complete is Component.Name. To understand what needs to be entered in this column, refer to NBIMS clause 22.214.171.124.2.86:
A component name is therefore a reference code or name that is used on a drawing or schedule. To be a valid COBie entry, it needs to match. This will vary for the exact component being reported, but in the case of a door, this would usually be the door number:
When aligning this to any authoring tools, it should be easily possible to relate that to the exact property which would be filled in for the door number. There are numerous BIM authoring tools available, but for the purpose of this guide, using Revit would normally require the instance’s Mark parameter to be used.
The image above would not be valid COBie, it is merely an example of how parameters map to the COBie field to help make it clear. The actual COBie sheet would require the door number, e.g. 1, 01, D101, or however the drawings / schedules refer to each door.
This means it should be a reference to the relevant Contact.Email who is responsible for generating the component in COBie. This may be the designer or technician who produced the model or, as noted above, it may be better if this is a general company contact as individual responsibility may not be possible to assign.
This would typically be added by the software generating the COBie output.
This is the date that the COBie data was generated or updated. BS1192-4 specifies that this format should follow BS ISO 8601 using YYYY-MM-DD, with the exact time optional.
This too would typically be added by the software generating the COBie output.
The Component.TypeName is a reference to the Type.Name field.
As with Component.Name this must match the reference used on the drawings / schedules. It is the common definition for all the placed instances. Multiple components would usually be expected to refer to a single type.
Using Revit as the authoring tool example again, this could be expected to be a door’s Type Mark.
A reference to the space name from where the component is accessed or maintained.
Once again, it must match the drawings / schedules. In terms of spaces – typically rooms – the “at the equivalent project stage” becomes important. A room may be referred to differently as the design stages progress. In early stages, there may not be room numbers allocated, only a general occupancy use (e.g. “Office” or “Administration”), which may change to room numbers through stages 3,4 and 5 (e.g. “R101” or “01.001”).
And so on…
What becomes clear as you understand what values need to be entered is that the sheets all cross-refer to each other. Without one sheet being completed correctly, the others will be incorrect. BS1192-4 defines the essential relationships in section 6.3.1:
If may be better to represent that visually, building it up piece by piece. The diagrams below show COBie fields and their equivalent IFC reference.
- A Component belongs to a Space.
- While it can belong to more than one, it would normally be assigned only to the Space from which it is “used, inspected or maintained”.
- A Space does not have to have any Components in it, although this would render it pointless.
- You would expect each Space to have multiple Components.
- A Component is of one certain Type. You would order a certain number (instances) of a specific sort (type).
- There has to be at least one Component of each Type.
- A Component also should belong to a System. It may belong to multiple systems, depending on its use.
- Although it could theoretically contain no Components, a System would be expected to have multiple Components.
- Systems are not related to Spaces or Zones, and in fact may span across several. Only their Components relate to Spaces.
- A Space belongs only to a single Floor
- It would be usual for a Floor to have multiple Spaces, but it may contain only one. It must have at least one.
- A Space must also belong to at least one Zone, although it may belong to multiple Zones.
- Zones are “aggregations of spaces that provide some common purpose” so would usually contain multiple Spaces. They may contain only one Space, but they must contain at least one.
- Zones and Floors are not directly related, as Zones may span vertically over multiple floors.
- All Floors and Zones belong to a Facility. Although this is not specifically defined in BS1192-4 section 6.3.1, COBie output must define a Facility.
- By implication of the fact that there is no reference to the Facility sheet, each COBie spreadsheet should define one single Facility.
- A Facility belongs to a single Site. This is specified by the Facility.SiteName field.
- A Site may have multiple Facilities, but as implied above, each would be delivered in its own COBie spreadsheet.
Outside of the sheets required in COBie, one that can be very useful is the Documents sheet. This is used to identify external files related to data in other sheets. An example of this might be performance specifications associated with Types.
Basic details would include:
Name = The name of the document. This might be different to the filename, especially if an extranet or EDMS is used.
SheetName = a reference to the COBie sheet to which the document is associated. For a performance specification this would be Type.
RowName = the specific row to which the document applies. Note that this should not be completed as a row number, but by using the unique Name entry. In the example above, it is referenced to Type.Name (which of course should be replaced with the actual entry e.g. “Door Type 01” or similar).
The Directory and File fields provide exact folder paths and names of the documents. BS1192-4 recommends using hyperlinks for these.
The Attributes tab is not a required sheet. It is common to find every property on every component or type listed out on this sheet. Far from being helpful, this serves to make COBie more difficult to interpret and utilise. Required Attributes should be specified in the EIR or omitted, and as BS1192-4 clause 6.5.4 states, should not include:
BS1192-4 section 7.7 defines additional “expected attributes” for UK BIM Level 2 projects.
The COBie schema is able to be extended where necessary to include any additional information specifically required by the EIR.
If additional sheets are needed, they should be added after the final PickLists sheet.
Additional columns should be added to the right of standard COBie columns. An example of this might be adding multiple classifications to the Type sheet. The Type sheet has Type.Category for one classification only.
 BS1192-4 clause 3.2
 PAS1192-2 clauses 3.27, 9.1.4, 9.4.4, 9.5.3, A.72; BS1192-4 clause 4.2.1
 BS1192-4 clause 3.6.6 note 2
 BS1192-4 clause 6.3.1
There are no reviews yet.