Welcome to the fifth and final part of Yondr BIM manager Steven Adams’ journey towards understanding COBie. Adams is a draughtsman by trade who learnt Revit and then BIM, which brought him to COBie.
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.”
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.
‘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’
Steven Adams
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.
Light at the end of the tunnel
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:
Schedule heading
Example
Aligning COBie Field
Dry Weight (kg)
8345
Component.TypeName > Type.DryWeight
Operating Weight (kg)
9215
Component.TypeName > Type.OperatingWeight
Sound Power Level dB(A)
85
Component.TypeName > Type.dBA
COBie clicks
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.
COBie is for tools not humans
“Other than COBie gurus, no one will (and I don’t think should) ever understand a COBie file.”
Steven Adams
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.
My rules
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.
The key lessons
I think my five key takeaways from my story and the advice I would give are:
Understand the structure, what a relational database is, what Primary and Foreign Keys are, and how the COBie sheets link together.
Look at what is delivered in your design documentation. What information is on the engineers’ Excel schedules, what is in the specification. This is all the same information that is in COBie. COBie shouldn’t be asking for more than what is normally provided.
Understand why we are doing this. It is a standard format of information already designed. What’s on drawings and schedules is presented in a different way that can be used for a multitude of purposes.
Standardise deliverables. Get a structure for what the equipment schedules look like and have them presentable as project documentation for engineers to fill in, check and validate. These can be set up in your authoring software templates: they then get populated as you model. They can all be mapped to COBie fields. Standardisation leads to automation, which leads to efficiencies. No more “it takes six weeks to add the COBie data at the end”.
Other than COBie gurus, no one will (and I don’t think should) ever understand a COBie file. It needs to be interpreted for them, same as any database. Tools need to be developed for this by the gurus!
This is not a first step towards a paywall. We need readers to register with us to help sustain creation of quality editorial content on Construction Management. Registering also means you can manage your own CPDs, comments, newsletter sign-ups and privacy settings. Thank you.
