My journey to understanding COBie part 5: enlightenment

In sharing how I use COBie in this series, I hope to help others struggling to grasp it as I once did.

In the four previous parts I detailed how I compiled what I would expect to use for each standard field. However, I realised there was more information than I would usually provide in an equipment schedule. I need to look at the Attribute Sheet.

The Attribute Sheet is an interesting one. Column A, like all the other sheets I’d come across, has duplicate values in the sample file, so couldn’t be the primary key. The NBIMS states: “Attribute.Name, Attribute.SheetName, Attribute.RowName, Attribute.Category comprises the compound key for this worksheet.”

Attribute.Name is a name for this attribute, so I thought “TypeMark” for my Type Mark requirement. Attribute.SheetName and Attribute.RowName look up a sheet and a primary key on that sheet. So for my type marks, the Attribute.Sheet is “Type” and Attribute.RowName is the “Type Name” of my luminaire.

There can only be one value for each attribute name, so I thought a concatenation between Attribute.Name, Attribute.SheetName and Attribute.RowName would be unique. I wasn’t sure where Attribute.Category came in.

We have Attribute.Value to put the actual value in, so “A” for my luminaire type “A”. This attribute sheet was going to get big: I needed a row for each attribute for each type, component and space. As I thought I should include DryWeight, OperatingWeight and dBA for a lot of equipment, it seemed to be overkill.

In the BS 1192 part, I noticed something in the General Structure clause: “Any additional columns specified by the employer should occur to the right of the final specified columns and should have a header column name. NOTE 5 Such columns might be read by receiving applications, as if they were textual Attributes. They can be used to simplify the generation of COBie information where the Attribute is applicable to the majority of the objects on the sheet. For example, if all or most Spaces (locations) are expected to have a “FloorCovering” value, then such a column can be added.”

Well that would make the COBie file a bit easier! However I hadn’t successfully managed to add extra columns on any of the sheets using the BIM Interoperability Tool in Revit. Since moving to my appointed party though, one of our lead appointed party’s BIM team had managed to do this using IFC files and Solibri.

Either way, I could export the system parameter for Type Mark in Revit to either map to an IFC parameter for Solibri, or set up the BIM Interoperability Tool in Revit. Happy days.

I added the following three lines to my equipment schedule mapping table:

All of a sudden, I felt COBie had clicked with me. I could see the relationship between what I would normally provide in design documentation and what COBie should have. Trying to almost reverse engineer the COBie file, I could see the intention and now the use.

Since working through the sheets I was primarily concerned with, I changed roles to work with an appointing party. Now I’m the end user of the data, it’s extremely clear I need to set exact requirements, and also be able to check that they’re compliant. If I give someone an option of “N/A”, everything in that column will become “N/A”.

I’ve developed what I created above into a table giving the COBie fields and examples, the explanation of what’s required and at what stage. I’ve also created the “human-readable” schedules in my now infamous “712” document that sets out standard schedules that our engineers want to review. These of course map to a related COBie field.

It has taken some years and a few projects, but the data is getting better and better. We use this COBie data to create an “Asset CV” so we can trace everything that’s happened to an asset throughout the entire design process and into operations.

I always have doubts that I’m doing the correct thing, and am nervous sharing these experiences and exposing myself to the world. I certainly don’t think I have this 100% nailed, and I’ve not even discussed the Jobs, Issues and Resource sheets yet – and they’re key for the actual purpose of COBie at handover. However, surely we can’t get those sheets correct until we get the Component and therefore the Type sheet correct?

I still get questions about “Are we asking for the correct amount of detail?”, as the cost of paying someone to enter this information has to be rewarded by having the structured data. We need a ROI, otherwise what’s the point? All I can say is if I went back to either a consultancy or contractor role, this is how I would want to develop my deliverables. Establish standard schedules, then ensure they‘’’re mapped to COBie fields.

Another discovery is that I can’t really expect humans to interpret COBie. I need tools to do that. There’s a QC checker, but it requires Java to be installed. It would be great to have an executable to run the programme.

I’ve managed to create Excel tables using the “Index” command to turn COBie data into schedules. But I still need to copy/paste the data from the COBie sheet to my sheet, so it’s still cumbersome.

I have a PowerBI expert that can check and create specific schedules. However, the principle of COBie is that it’s universal. My wish is that my engineers are able to use a programme, website or tool that can load a COBie file and get whatever data they want from it.

I used to write Visual Basic games in Excel many years ago, so I wonder if I can remember how that works and develop something. It’s already in Excel so it seems a logical place to start. If anyone wants to use my definitions as a starting point for theirs, or just tell me where I’m wrong, or comment to come together and create a sensible approach, I’ve tabulated them here: Steven’s COBie Rules.

I’ve added some extra fields as I’ve developed our Exchange Information Requirements, and also further definitions of sheets like Facility, Systems, Documents and Issues. I might write about these in the future: how I came about the definitions and the thought process of why I added them.

I know the major point is for the client to understand what information they want. However, I feel there needs to be at least a starting point for the client to say, “Yes I want that, no I don’t want that”. If there was a sensible starting point developed between information providers and information users, it would help stop the “What do you want?”/“What can you give me?” cycle.

I think my five key takeaways from my story and the advice I would give are:

Don’t miss out on BIM and digital construction news: sign up to receive the BIMplus newsletter.