Transfer of data needs to move beyond spreadsheets, which means it’s time to kill COBie, says senior BIM engineer Andrew Hannell.
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.
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.
Comments
Comments are closed.
If not COBie then what? – you don’t really answer your own question with a working solution. But I’ll let that pass.
There is a more pressing issue with COBie and that is not one of our clients has mandated a COBie data deliverable as part of their EIR. In fact most employer’s still haven’t got their heads around an EIR let alone COBie.
Moreover, and you do touch on this, there is the consideration of who maintains FM data and what FM data needs to be maintained anyway. Perhaps the industry should be seeking answers to these questions first.
The thing is, most employers won’t want to pay loads to maintain asset data they don’t need or use and in a lot of cases they don’t do this in house anyway but outsource FM/asset management services. So are we talking to the right people about lifecycle data? Do the FM/asset management teams sit in at project briefing time for example?
And anyway a lot of the larger employers with big asset estates have separate teams and budgets between procurement and operations and often these groups don’t talk to each other even when they know each other exists at all. So employers need to sort themselves out here perhaps and bring their teams together to look at the bigger picture that is the asset whole lifecycle.
However, COBie has made a start by at least making people think and discuss the issues of information management, where it lives, who is responsible for creating and maintaining that information and providing a relatively simple, if very cumbersome, solution to the lack of software application interoperability. It has also brought many different people and their vested interests to the table to start figuring out ways in which information (graphical and non-graphical) should be created, processed, transferred, utilised and maintained throughout the whole asset lifecycle and what level of detail is needed by different lifecycle contributors at different times on the lifecycle timeline. This alone is a massive culture change for everyone.
The industry has a very long way to go before lifecycle information can be passed between design, construction and operations and round again in a seamless way. IFC doesn’t cut it either yet. But it will come and COBie is just a very small stepping stone to the ultimate visionary goal of fully interoperable asset information. This is where the most money can be saved for employers/asset owners in the long term.
So, give COBie the benefit of the doubt perhaps. In years to come we’ll look back and thank the people who originated and developed COBie as we thanked Microsoft and IBM for the original PC. That was a clunky out of date as soon as it was created device and look where we are now…
So true, everything in this article is right on spot. Thats why we always are talks about integrated solutions for a unbroken information flow from early phases, design, construction, FM and back again to reconstruction.
I hate COBie and always have – it’s old tech, clunky and not fit for purpose, but the fact it has it’s very own British Standard (when PAS1192-2 is still a PAS) shows the commitment for a means to transfer design and construction data to FM. The best solution will need to be created by the next generation of FM, not the current, and will need to be a visual UX linking model, text and (gasp!) live analytical data. If a client wants to manage an asset for 25+ years, then the interface needs to be bleeding edge tech now so it is normalised upon mass adoption. I love a good spreadsheet, but sadly, COBie isn’t one of them.
Hold on now you lot this ain’t the wild west or some would think it is, yes it’s not the greatest tool in the box but it’s a tool and until we have something else or we update the existing then we just have to put up and shut up.
Maybe we should look at a BIM mantra of – Don’t bring me problems, Bring me solutions.
COBie doesn’t require BIM. Just like IFC doesn’t require BIM. It just makes sense to use the schema with data populated in models. You don’t quite understand what COBie is I am afraid. It’s just an asset register. But uses the IFC schema to help structure, standardise and map data. Without IFC, then it’s just a bespoke register incapable of international QC. And 99% of all FM contractors can only consume data in Excel or Excel mapped mediums like CSV
Missing the point the lot of you.
COBie was never intended to be used as a database. It’s a data exchange mechanism. At least it encourages people to think in terms of structured data. And I’ve worked on several projects where a COBie deliverable WAS a requirement. Yes it is a blunt instrument, yes it is the lowest common denominator but the majority of industry doesn’t have the luxury of being at the cutting edge with you guys. Many organisations are barely at Level 1 in old money (oops almost started talking about Level 2! tut tut!). So using excel is a bridge.
Get real.