My journey to understanding COBie part 4: filling in the blanks

COBie: data and buildings image
Image: 216575231 © BiancoBlue | Dreamstime.com
Welcome to the fourth instalment of this five-part series detailing how Yondr BIM manager Steven Adams came to understand COBie.
Adams is a draughtsman by trade who learnt Revit and then BIM, which brought him to COBie.

In part one, I covered how I began to understand the terms and structure used in COBie, and built my asset list. In part two, I shared how I linked assets to type and how I came to realise I don’t need everything at every stage. In part three, I returned to the type sheet as I continued to develop my understanding of the framework. Here, in part four, I chart allocating the space (or location) for each item.

I’d started my Component Sheet and my Type Sheet was looking reasonable. I needed to go back to fill in the blanks on my Component Sheet and allocate a location (known as a space in COBie) for each item, therefore I needed a space sheet. As an M&E consultant, that’s not my job, but I needed it to make my list work. Also, since I’d begun working all this out, I’d joined an appointing party, so I did care about the space sheet!

Field heading: Component.Space
Steven Adams, BIM manager at Yondr

“Hold on though… I don’t want people emailing me about the projects. They should be contacting the project engineers and managers.”

Steven Adams

NBIMS description: “A foreign key identifying the COBie.Space.Name. For components not contained in a single space, the value shall refer to the space from which the equipment is most likely to be maintained.”

The key for me here was the “a” and “the”. The way this reads, it certainly sounds singular. I’ve seen COBie files that list multiple spaces when an object straddles rooms, most commonly doors.

Field heading: Space.Name

Stated as the primary key, so this needs to be unique.

NBIMS description: “The Space.Name must match the value found on design drawings at the equivalent project stage of the current deliverable.”

The most sensible choice here would be what the architect has numbered the room. These should always be unique, and I can use the inbuilt Revit tool to copy the architect’s room number to my model.

We have a couple of other foreign keys here for category and floor name, which look up the Floor Sheet. At that moment I didn’t need those for my M&E asset list so passed on them for now.

Field heading: Space.Description

NBIMS description: “The description of the space found on design drawings at the equivalent project stage of the current deliverable.”

The only other thing on a general arrangement drawing I can think of, apart from the room number which we have in “Name”, is the actual room name. This will confuse everyone: the number is the Name and the name is the Description.

Other fields are optional and I shouldn’t be producing those anyway, so the final one is the contact sheet.

Field heading: Contact.Email

This is the primary key, so all those email addresses I added for CreatedBy, Manufacturers and Warranty Guarantors need to be in this column. The first one was me as I’d entered data and needed a lookup for the CreatedBy fields on every sheet.

Hold on though… I don’t want people emailing me about the projects. They should be contacting the project engineers and managers. So I had to make this the default company email. The same would apply for the manufacturers.

Field heading: Contact.CreatedBy

“It finally twigged that Contact.Name is the primary key for a specific company, and the CreatedBy is the person entering that information.”

Steven Adams

NBIMS description: “The contact email of the person or company creating or updating a row of COBie data.”

Yes, this is common for all the sheets, but it frustrated me. I’d already typed my email address in Contact.Name, so why did I have to do it again? It finally twigged that Contact.Name is the primary key for a specific company, and the CreatedBy is the person entering that information. These can be two different people, it just happens that the first thing we need to do is put in our own contact.

Field heading: Contact.Phone

Is this required nowadays? Do you want my fax number too?

The rest are reasonably self-explanatory, although I’m not sure I want to use Given Name and Family Name. Surely the company is enough? Even if I looked at others’ COBie files, I’d probably see the BIM person’s name, who might have moved on.

I thought I’d completed the sheet enough to produce my equipment schedule.

Except… I wasn’t signing off an equipment schedule. That’s my engineers’ responsibility. I’m chucking out drawings and schedules for them to approve. They’re also not going to review a COBie file and they’re not going into my model.

“Must match the value found on design drawings” is specified several times in COBie in various ways. The same way I’ve set my tags up in Revit to read the parameter of the object and the schedule referring to the same parameter, surely I could set the COBie exporter to look at those same parameters? Then if the engineer signs off the schedule and the drawing, my COBie file will contain the same data.

I’d already started to standardise our schedule deliverables so I just needed to work out what goes where.

My Capital Plant and Equipment Schedules ended up aligning like this:

Schedule HeadingExampleAligning COBie Field
Equipment ReferenceGEN1Component.Name
Equipment DescriptionGenerator 900kVAComponent.Description
ManufacturerSDMOComponent.TypeName >
Type.Manufacturer >
Model1234Component.TypeName >
Rating/Size900kVAComponent.TypeName >Type.Size
Width (mm)2000Component.TypeName >
Length/Depth (mm)6100Component.TypeName >
Height (mm)3000Component.TypeName >

I was slightly perturbed. I had a lot fewer fields in my Equipment schedules than in my COBie sheets, although I’d already decided a lot of the fields in COBie weren’t needed until Stage 5 or 6.

I recognised that I was also going to have difficulty looking up the Contact Sheet within Revit. They aren’t created as Type parameters and I wanted the plain English company name to appear in my ‘human’ schedules. So there was a bit of work involved, but I decided to continue to use Revit’s System Manufacturer Parameter for that, and the Contact.Name for COBie. I’ll have to ensure my contact sheet reflects the same.

I also had some information missing here. I’d normally have Dry Weight, Operating Weight and dBA, to name a few. Surely I wanted to tie that in too?

I also wanted to create a Fixture schedule, but certainly not list every instance.

Schedule HeadingExampleAligning COBie Field
DescriptionLinear luminaireType.Description
ManufacturerThornType.Manufacturer >
Type MarkAAttributeTypeMark >
Quantity50Calculated in Revit

This is where I needed the Type Mark. I couldn’t only include it in Type.Name as it wouldn’t read correctly. I decided to include that as an attribute for my fixtures.

Back to Type.Name, I decided to settle on the Revit Family and Type Name. I couldn’t see anything else working here, and it’ll never appear on a drawing or schedule, so it’s only to make the COBie spreadsheet work. Plus, using the Family and Type name would ensure uniqueness. So it appeared that I need to use the Attribute Sheet.

In the fifth and final part [to be published at 11am on Wednesday 2 November – ed], I’ll look at adding the extra parameters and pulling everything together.

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

Story for BIM+? Get in touch via email: [email protected]

Latest articles in Explainers