Let’s face it, COBie is the BIM equivalent of the two-inch thick phone directory that we all used to receive every year – it’s out of date even as it lands on your doorstep.
COBie would be fine if buildings, structures and other assets were static and remained in the same state as the day the constructor handed over the keys (along with the COBie spreadsheets). But this is not reality, things get added, removed, altered and replaced over the lifetime of a building.
This is not a paywall. Registration allows us to enhance your experience across Construction Management and ensure we deliver you quality editorial content.
Registering also means you can manage your own CPDs, comments, newsletter sign-ups and privacy settings.
Although data may originate from a model, since COBie spreadsheets are essentially independent, any change in either model or spreadsheet has to be manually synchronised.
Read related article
It is not necessary for all data to be stored in a model and there are many reasons not to load models with too much data, particularly geometric. But, the model geometry and attribute data does need to be linked in some way, so that a change only has to be made once – and this is where COBie fails.
– Andrew Hannell
I understand why a set of Excel spreadsheets seems like an attractive proposition. After all, everyone knows Excel, which makes it convenient and easy. However, it is the absolute lowest common denominator of technology and a terrible way to transfer information, only marginally better than the 1kg of yellow paper.
Whilst COBie is intended purely as a transfer mechanism and not as a usable spreadsheet, the most widespread format of COBie as Excel (as opposed to other flavours such as the XML COBieLite) means it often is a spreadsheet.
It is not necessary for all data to be stored in a model and there are many reasons not to load models with too much data, particularly geometric. But, the model geometry and attribute data does need to be linked in some way, so that a change only has to be made once – and this is where COBie fails.
Better than nothing?
It is beyond me why PAS 1192-2 gives COBie so much credence. Perhaps it is a case of anything is better than nothing?
The BIM Task Group website does talk about “ordinary databases”, although it also mentions “copy and pasting” the data into FM applications. Surely, we can come up with something more sophisticated than copy and paste?
The recently released Navisworks COBie plug-in is just a band aid solution. It might help harvest, or push data back and forth between (published) model and spreadsheet, but it is a technical dead-end as attribute data is now independent of the original (native) model.
A maze of cryptic field names
The COBie schema and templates are a maze of cryptic field names, child and parent fields that need to be updated in numerous places for it to all make sense. Many of the attributes are baffling, such as “YawRotation” – why would anyone need to know this?
On a technical level, COBie tries to turn Excel into a relational database by the use of manual joins such as “Value must be found in referenced Foreign Key List”. Only database geeks will know what that means.
If not COBie then what?
BIM authoring applications, as used by architects and engineers during the design and construction of an asset, are obviously not appropriate for the owner, operator or asset manager.
The information needed for ongoing operation and management is very simple, and much of the information produced during construction is superfluous. Owners and managers should not have to become BIM experts, but they should be able to query and maintain their data with appropriate tools.
Therefore, FM applications and data standards need to be model-based, with suitable tools to maintain the model data. In other words, the BIM wheel needs to be a full circle, using proper model-based techniques over the entire lifecycle, rather than dumbing models down at the end of construction.
