Current Filter: Construction>>>>>Technology Focus>

   

Oh no, I hear you sigh - another article about COBie. For what it's worth this is my take on some of the matters that concern and confuse us about the elephant in the room.

COBie has and will continue to receive bad press, and I think some of it stems from a severe lack of understanding by the parties who request it, and pretty much constitutes laziness in learning it. I believe that some of the bad press is unjustified and perpetuated by people with a commercial interest elsewhere. You need to have an open mind when reading these articles, in other words.

There are some great blogs about COBie which are easy to find. The LinkedIn group dedicated to it for example is very popular, and if you're not following it already I suggest you give it a look: www.linkedin.com/groups/2638637

One of my issues with the subject of COBie is that it's often dismissed before it's even had the opportunity to demonstrate its potential. I believe this is partly due to the hype that surrounds the scaremongering and bad press it's receiving in some quarters. Another possible reason is that the managers responsible for specifying it don't want to understand it and are instead preferring to make it up as they go along and go 'off-piste'. In essence they are attempting to take an easier route, in their view.

Unfortunately, when COBie is dismissed it seems all manner of common sense is dismissed as well. I understand that developing your own information exchange can be an extremely successful solution and one that's often implemented well. In some circumstances I would wholeheartedly support this route and I am involved in developing routes such as this. However, people come and people go. What's the likelihood of a successor inheriting a bespoke information exchange schema and being happy with it - and not wanting to change it? Very unlikely, in my opinion. People like to make their mark and rubbish other people's work for selfish, self-important reasons. I see this as a time bomb.

It is also likely that errors and issues will be exposed as a bespoke information exchange schema never comes with anywhere near the extensive instructions that exist with COBie. Quite often fundamental things are missing - object naming standards and date formats for example - and invariably there are no pick lists or even indication whether it's a Type or Component Parameter, thus making validation and verification near impossible. This is a fundamental requirement to ensure you have received what you asked for.

This leaves it open to interpretation, and it will be interpreted differently by all parts of the construction team. It will be passed onto subcontractors with #nofilter and this will result in only one thing - risk! And how do we deal with risk? Add cost all the way through the supply chain. That’s quite the opposite of what BIM and COBie were designed for and are in fact supposed to remove.

These ambiguities should be queried, however for that we need time to query the requirement and the person requesting clarification, and identifying the need for clarity. This is reliant on them being sufficiently knowledgeable about the process of information exchanges - and quite often they are not. Inevitably we must also remember that ambiguity could be seen as opportunity.

So the bottom line is that it all comes down to the brief, and even if COBie is specified it needs to be specified well, as again a lack of information about what you want from COBie will inevitably open the process up to interpretation. And, again, this will add cost all the way through the supply chain. Ah the brief, I hear you say. It's difficult enough extracting a brief for the building and its use let alone its digital asset information. However, it's this information that has the potential to reap the rewards quoted on life cycle, so its importance should not be downplayed. Yes, I acknowledge we have a responsibility to educate our clients but they also have a responsibility to educate themselves.

To summarise, there are two fundamental points I am trying to stress: use COBie for what it was intended and, if that is not sufficient, develop additional information exchange requirements above and beyond COBie, ideally using the many unused property sets within IFC - but there is no need to reinvent what COBie can give you. Likewise there is no need to reinvent IFC schema. Use it and you have a data structure. This will identify the gaps in the information exchange which should be relatively easy to fill with another sheet, and build on COBie for your own additional information.

If you are writing a brief, specification or EIR that includes an information exchange I urge you to stick with COBie as it’s well documented. However you need to be specific about what you want from it, and this is summarised here on the LinkedIn group by the creator of COBie himself, Bill East: https://www.linkedin.com/groups/2638637/2638637-6081100718201200643

THE THREE QUESTIONS...
Owners need to answer three critical questions if they want COBie data they can use. Why? Because COBie is the only the format to deliver handover data. COBie can't possible predict the specifics of an individual owner or project. Here are the questions:

1. What assets do we manage? The Owner should look at what they actually maintain over time. The default position of getting 'everything' distracts the team from the Owner's real needs.
2. What information do we need? If Owners need the fan belt size for fans then say so in writing. Without such specifics Owners can expect to get whatever is given, and have to like it.
3. How will it be organised? Campus/Installation owners with a consistent Classification method for COBie.Space and COBie.Type will be able to mine data.

Sticking with COBie will give you the confidence in what you have asked for, confidence in the longevity of the schema, and confidence when personalities change. There should be no additional learning as COBie will get to be well-known, and you will also have the security when questioned that you have an industry standard data scheme and information exchange.

I would say that if you're choosing to write your own information exchange schema you will need to put a considerable amount of additional work into it than specifying COBie correctly. If you don't know or have the skills to do this then seek good advice.

Until we have affordable semantic web solutions for the collection and management of asset information that are well tested and embedded with confidence I advise you to stick to your guns and don't go 'off-piste' unless you're really sure it's the right thing to do. Again - get good advice!
www.bimtechnologies.co.uk