Decoding COBie: Understanding its true purpose in AEC

Decoding COBie: Understanding its true purpose in AEC

COBie is the opportunity for the supply-side of designers and constructors to deliver to the owner/operator the information needed to operate and maintain their facility from day 1. It can be thought of as a simple suitcase with the foam inserts with a place for everything needed with no wasted space or danger of the contents rattling around. It isn’t a 40ft shipping container you can fit (almost) anything into. But it is always an “information exchange” – a transaction that delivers information. Unfortunately, people have often projected all sorts of other expectations onto COBie, making success harder. 

Let’s look at some things that COBie is NOT, and why…

1. COBie is NOT a portfolio, asset or facility management application. COBie stands for “from Construction into Operations of Buildings – information exchange”. As an experience-hardened colleague once explained it can equally stand for “Can’t Operate a Building in Excel”. The point of a structured information exchange is to let suppliers collect the information without worrying about the owner/operators applications – which may be unknown or change.

2. COBie is NOT a digital twin. It is a snapshot taken at handover of the information held by the Constructor. Any additional drops prior to that are waypoints towards that handover. The only reason for preparing a COBie delivery package is if it is going to be loaded into an owner/operators application(s). 

3. COBie is NOT a Building Information Model. It only represents equipment, such as mechanical, electrical, plumbing and transport devices, and, on the structure and fabric side, only doors and windows, along with the context to find and identify them.

4. COBie does NOT need any specification of the equipment to be included. NBIMS v3 p215 gives a sufficient list of exclusions – in ISO19650 terms, NBIMS v3 standard IS the Exchange Information Requirement. COBie does NOT need to have the required attributes (properties) specified. Again, NBIMS v3 is sufficient. For example, only things that have a classification and a unique name are even candidates to be included. COBie does NOT need to be specified for relationships. Yet again, NBIMS v3 is sufficient, as it defines the cross relationships needed. Any piece of equipment must be related to a product Type and a Space . The Space must relate to a Floor. The product Type must be related to its Jobs and Spares.  

5. COBie does NOT need to have the required attributes (properties) specified. Again, NBIMS v3 is sufficient. For example, only things that have a classification and a unique name are even candidates to be included. 

6. COBie does NOT need to be specified for relationships. Yet again, NBIMS v3 is sufficient, as it defines the cross relationships needed. Any piece of equipment must be related to a product Type and a Space (or location) . The Space must relate to a Floor (or region). The product Type must be related to its Jobs and Spares.  

7. COBie does NOT have to be a spreadsheet. OK, it usually it is, as this is the most obvious way of making it checkable on the supply side and readable on the receiving side. An alternative is the subset of IFC defined in NBIMS v3.

8. COBie does NOT need to use Excel. It uses any spreadsheet software that supports using the open XLSX format which is a compressed XML. XLS is not COBie.

9. COBie does NOT necessarily come from BIM. Much of COBie should be in BIM by the end of the design stages but some of it just can’t be. The gathering of Contacts, Documents, and Jobs, Spares and Resources may have to be managed separately. Luckily, there are tools to merge spreadsheets.

10. COBie is NOT an isolated deliverable. It must include the schedule of associated documents , such as general arrangement drawings associated to Floors and Spaces or product data associated to Types.

11. COBie design sheets can NOT be exported from BIM, until you have added classification to Facility, Spaces and Types.

12. COBie does NOT have to contain US Omniclass. In the UK Uniclass is part of the UK Government Information Mandate and the UK National Annexes to the ISO19650 standards. There aren’t many other classifications systems that cover both Spatial and Physical objects.

To sum up, its vital to develop a repeatable process for creating COBie. That process must accurately filter your information, check for omissions and then lay it out exactly as required. COBie can be easy and it makes for a better handover!

Missed our webinar, “How to enhance your COBie design worksheet?” ft. Nicholas Nisbet and Ward Turkyeh?!

Sign up today for your exclusive session and acquire technical knowledge about COBie implementation!

Contributor

Owner at AEC3 and
Vice Chair at BuildingSMART UKI

Owner at AEC3 and
Vice Chair at BuildingSMART UKI