BIMBeing: The Journey #6

#6 – COBie: Academia won’t save us…

Photo by Pixabay of Pexels

Construction Operations Building information exchange – COBie. Possibly one of the most misunderstood parts of our industry and yet it’s one of the most talked about, and that’s part of the problem. There are people continuously nattering on about COBie, at every single event, but hardly anyone is successfully delivering it – especially those doing most of the talking. Everyone is spurting theory, we’ve all had enough. “He who shouts the loudest isn’t always the most knowledgeable”. That couldn’t be any more applicable than here.

Recent events have been no different; many people presenting COBie and plenty of vendors claiming their software can produce it with ease but still little hard evidence of a complete deliverable in sight. Why is there no evidence? Because most have never done it, not to a robust and presentable standard anyway! Every COBie talk I’ve been to across multiple events have always been the same: the importance of the client is stressed to breaking point, the word collaboration is thrown around 50 times and finally somebody says “it’s really not that difficult”. We’ve heard it all before, this charade has to stop.

Unfortunately for the academics out there, I’m about to put some blame on you. You’re doing a lot of the talking, pumping everyone with theory and telling us how not difficult it is and that is leading to an epic case of assumed knowledge (If you’ve not read Post #1 where I introduced assumed knowledge I would recommend that you give it a go). I know this for a fact because I almost stumbled down the same slippery slope of assumption not too long ago – it’s very easily done. Still new to the industry and having never knowingly contributed to a COBie deliverable I was unaware of the hidden complexities and sheer volume of work it entails. However, I’d heard several talks at events like DCW and been repeatedly told how it ‘wasn’t that difficult’, so I started to believe it. I started to assume that it would be a simple case of ‘collaboration’ and button clicking and when moving onto my first project with a COBie deliverable I therefore wasn’t concerned at all. But then I started really looking into it, stopped listening to the talks and started trying to plan what actually needed to be done. To call it simple is quite frankly beyond a joke.

I’m not going to sit here and tell you it’s impossible but I certainly won’t give you the false hope of it being easily achieved. Project size dependant you’re looking at hundreds of thousands, if not millions, of data entries all of which must conform to the specified format. And getting the format of the data correct is only step 1, what data you actually put in is a whole other story (and a long one at that). As a main contractor especially it requires an in depth understanding, an impeccably practical approach and an awful lot of planning to have any chance of delivering a good COBie file suitable for RIBA Stage 6 (delivered for Stage 7). So, when an academic is standing on that stage in front of you telling you “its not that difficult”, remember this: they have probably never worked on or delivered a complete and compliant COBie on a real project, they’ve never compiled the information required for COBie from a long list of project stakeholders (clients, consultants, sub-contractors, suppliers) and if you listen carefully they’re not actually telling you how to do any of it. It’s all make-believe and for the construction industry it really is a crime.

Off-topic, but take the vehicle emissions scandal. Those engines performed perfectly in a lab environment, meeting or exceeding every criteria that was set and therefore being sold across the world as achieving a particular standard. Not just sold, but actively promoted on the merit of efficiency. Governments were even supporting them, offering incentives to purchase such efficient vehicles based on the data being supplied, based on people telling them how good they were – sound familiar? It was all a ruse. Move those engines out into the real world and suddenly we have a very different story. The real world demands of an engine are far from the perfectly simulated environment of a laboratory and that meant the engines could not perform as promised, not even close. Worse still, those formulating the results in the lab knew very well that they were being unrealistic but it took practical application to really show it to them. Once they knew the issues though they started to lie; they continued to promote the engine on false merit whilst secretly modifying the engine management data so that the great lie would not be undone. This is theory and academia against application and reality, and I think we have the same problem. COBie is being promoted by the guys from the ‘lab’, but out here in the real world it’s totally different.

The only way we move the industry forward and start widely producing good COBie data is to look beyond the academics. They’ve done their part now, they’ve helped create the standard and they’ve told us all of the wonderful things that can apparently be done. Now it’s over to us – the implementers, the practical champions that are on live projects producing real deliverables. We have to step up and find our own way.

Am I being a little controversial? Have I offended some academics and knowledge assumers? Probably. I warned from post #1 that you’d get the uncensored truth here.

This post was never intended to be a how-to guide, in honesty it was a post-event rant, but now I’ve got to this stage I’ve decided to add some hopefully useful notes. Consider the following snippets of information on the purpose of COBie and some of the key questions you need to answer before you start trying to create anything. It may not be anything particularly new but it should at the very least be some food for thought, some practical suggestions:

• Do you know where COBie started? COBie was originally created by William East of the United States Army Corps of Engineers who devised the schema to improve the handover of buildings and management of assets. It was not created to increase the amount of information that needs to be collected and handed over but was designed to organise the existing data in a consistent format that would enable it to be widely re-used. It’s a very important point, especially when talking contractual obligations and delivery requirements; COBie should not be considered as additional data – it’s just data organisation, data management.
• Do you really understand COBie? You cannot possibly plan a successful delivery strategy without a solid understanding, assumption won’t cut it. Have you read the BSI/ISO standards and really understood the format and requirements? Have you opened one of the template/sample files and had a look around to understand the structure? Have you read additional supporting information to get a more rounded understanding beyond the BSI/ISO jargon? I would highly recommend NBIMS-US V3 (National BIM Standard-United States Version 3) for example. Part 4.2 in particular and the associated annexes A and B provide exceptional detail on the specifics of COBie, including:
  • Clear descriptions of what each attribute is to be used for (i.e. what information is expected)
  • Defines the relationships between different attributes (i.e. if data in one attribute is a reference to information from another attribute)
  • Precise detail on the format of information expected in each attribute (i.e. Alphanumeric, Numeric, Picklist Values etc.)

These details really matter if you stand any chance of producing a compliant and useful set of information.

• Remember that COBie is not created to be read by a person in it’s clunky Excel form. A facilities manager will not be searching through thousands of fields of data looking for a Pump or a Fan Coil Unit. COBie is used to populate a database that will be used for Facilities Management (often referred to as a CAFM system – Computed Aided Facilities Management). Databases work on consistency; inconsistent data will render it useless. Naming conventions, data formats, completeness of information and classification systems are all crucial. Handing over lots of mismatched, incomplete information will not help anybody – do it right or don’t do it at all.
• COBie is for manageable assets, so think carefully about what really needs to go in there. Anything requiring regular/periodic maintenance or planned replacement needs to be captured which means mechanical items such as fans and pumps are obvious; these are the types of object that COBie is good for. Now consider other items such as building fabric and finishes. Do you need to capture partition walls or floor finishes? Is there any benefit to having these items in an asset management database? What do you manage or maintain in a fixed partition wall? Scope and purpose of the data is key.
• It’s a whole team effort. Although the list of required assets should ultimately come from the client side of the project (they will be using it for management after all, and it’s their building) the other project stakeholders must support them. If the client has asked for partition walls in COBie, challenge it. Ask them why this information is required and what they plan to use it for. If they’ve asked for hundreds of additional attributes for each item, again this should be questioned. Are all of the written ‘requirements’ really necessary? Abortive work doesn’t benefit anyone. This should also work both ways; if the client has missed something from the requirements that you feel is important, raise it. Make sure that the whole project team understands what is being delivered, why it’s needed and what it’s going to be used for. Keeping quiet and doing nothing until the end of the project and then blaming the client for lack of information is really not an acceptable excuse, we all have a role to play.
• Who is going to do what? It’s a simple question but it’s not easy to agree and define, especially on large and complex projects with a lot of information authors. If you can bottom this issue out before the production of information starts then you’ve already climbed half of the mountain. The ‘who does what’ needs to be very detailed and must include the parties responsible for model authoring and the parties responsible for providing information. Your plan needs to be granular – define who needs to provide each and every piece of information for each and every asset. It’s one of the most contentious issues and gets exponentially worse if agreement is not sought early in the project. Detail is king in this process, scope gaps will hurt you later on.
• Where will all of the information come from? This is another key item to agree as early as possible. Think about how the information will be managed, how the process will be agreed, contractual restrictions or potential issues with parties editing data that is not their own and in general the practicality of your process (e.g. does your painter or carpet fitter really need to be trained in model authoring software?)
  • Will every required attribute come from the model? Does that mean paying consultants/model authors to input suppliers information and site collected data? Or does it mean suppliers need to be given access (and probably training) in order to populate data in somebody else’s model? Is this practical? Is it achievable?
  • Will models be put into a database or other piece of software for additional information to be added? If so, which platform? How does it work? What might it cost? Who will have access? Have you checked the quality of the output?
  • Are you planning to edit COBie in it’s Excel format? Don’t. I would very strongly advise against this, it’s horrendous practice and shows poor process. It’s also incredibly unmanageable on a project any larger than a 2 bedroom house.
• COBie is a subset of IFC. If your project deliverables include IFC and COBie you need to carefully consider the relationship between the two and not just how you create them individually. For example:
  • Revit as an authoring tool can export to IFC and directly produce COBie (with the BIM Interoperability Tools plugin). This method may seem efficient but does have its complexities. Specific consideration needs to be taken for the consistency of the deliverable; just because both the IFC and COBie are created from the same source (i.e. Revit) does not mean that they contain the same information – quite the opposite. This method presents a significant risk of the IFC and COBie data not matching as the processes for creating them are very different.
  • COBie can also be produced from IFC but this method comes with it’s own challenges. Consider where information from the authoring software (i.e. Revit) will go in the IFC and then how you find that information and organise it correctly in COBie. You need to tell the authoring platform exactly where to put information in IFC, attribute by attribute, and then a different tool or software package is required with separate instructions for where IFC information goes in COBie. It’ not easy by any means, but it is achievable. To many it is seen as a preferable process as there is a greater relationship between the two deliverables. A thorough understanding of both IFC and COBie is required here; I have purposely over-simplified these descriptions because if we start talking IFC property sets and attribute mapping I will never finish this post.
  • If you’re delivering COBie through IFC know that not all IFC’s are created equal. IFC’s can be constructed in a variety of ways, depending on the source/authoring tool and the process employed. This brings further challenges on projects where more than one authoring tool is being used for delivery. Consider how information from a Revit produced IFC may be different to an ArchiCAD produced IFC and how that could impact your production of COBie. There are ‘good’ IFC’s and ‘bad’ IFC’s. There is also a much wider discussion on what good and bad IFC look like; different people on different projects will have varied opinions on what is expected. Your process from one project to the next will almost certainly need to adapt.

Still think it’s “not that difficult”? I’ll stop my list here because this post is rapidly getting longer than even I would want to read. If you take nothing else away from these several thousand words, take this:

Producing COBie is not simple, don’t be fooled into thinking it is. However, with a comprehensive understanding of the requirements, meticulous planning and robust agreements between parties it can be achieved. The devil is truly in every detail.

I want to follow this with future post on COBie and hopefully share some detail on specific challenges and ways to overcome them. Remember that commenting on posts is now active (scroll down) and my email address is below, I really would like to hear feedback on this one. This is still a hot topic many years after being introduced to the industry and I have no doubt it will continue to be a strong talking point. I just hope that the real implementers and practical champions start doing more of the talking, we need to drown out the relentless academic waffle…

Mr. Smith

smith@dbe.careers