Adams has worked for consultants and contractors since the late 1990s, primarily in building services and critical infrastructure, with exposure to architecture and structural design. Since moving from AutoCAD to Revit in the 2000s, Adams has been pushing for more joined-up design and improved efficiency of delivery.
In this first instalment of a five-part series, he shares the start of his journey through COBie.
COBie: it’s a term that makes a lot of people cry, panic, maybe feel a little depressed. When I was working for consultants and contractors I never really understood it. I never got the point of it, couldn’t see any benefit and all the guidance just explained the framework and failed to provide relevant examples.
I’m a draughtsman by trade, trained to produce 2D building services drawings using AutoCAD for M&E consultancies and contractors. I learnt Revit to keep up with job requirements, which leads to BIM. Then management would fall into the trap of “BIM? Oh that’s Steve’s job. They want COBie, go sort it out.”
“I kept reading how COBie is about handing over to facilities, so why was I being asked for this at RIBA design Stage 3?”
Steven Adams
I would get into circular discussions with the lead appointed party, asking: “What do you want?” They’d reply: “What can you give us?” The appointing party didn’t seem to be involved at all.
I kept reading how COBie is about handing over to facilities, so why was I being asked for this at RIBA design Stage 3? We’re just throwing shapes at this stage. I kept seeing references to asset lists, so why am I being asked about documents, jobs, etc? I’ve seen COBie files that contain pipework elements and then heard others say those should be excluded.
After countless tries to source any real-life examples or training that answered my questions, I realised it would come down to me, just working it out.
Where to start?
So what did I already know?
COBie is a standard for exchanging information about buildings. Fundamentally, it is a list of all the assets (anything that moves or has power) in a building.
Or, as Dr Stephen Hamil, innovation direction at NBS puts it, it’s “a spreadsheet data format that contains digital information about a building in as complete and as useful a form as possible. In short, COBie is a Building Information Model.”
It can be automatically generated from the design model. When asked “why are we being asked for it during design if it is for handover?”, one speaker at a conference said: “It was to ensure you have the information in the model.” However, others say, as it is a spreadsheet, people can add information manually.
Armed with BS 1192-4, the National BIM Standard 4.2 (NBIMS - which I understand to be the origins of COBie), the sample file that accompanies NBIMS and information from several blogs, I put my focus on this with no distractions.
The result is this five-part series documenting how I came to understand and use COBie, built using my personal experience delivering the process and the intent to keep time to a minimum.
Working out the structure and listing my assets
“Coming from producing models, drawings and schedules in Revit, I could equate component fields to instance parameters and the type fields to type parameters.”
Steven Adams
My first step was to understand the terms described in the NBIMS. ‘Primary key’ and ‘foreign key’ jumped out at me as terms used in relational databases.
A primary key is used as a unique identifier for a row within the table to identify each entry. A foreign key is a column (or group of columns) used in a relational database to link data between tables, i.e. look up from one table to another. I’m not sure I’d twigged this before. This is what’s required to connect data tables, which in COBie are separate sheets in the Excel workbook.
Another, perhaps obvious, term was “must match the value found on design drawings”. I still feel there is a disconnect between what’s on design documentation and what gets included in COBie files.
Coming from producing models, drawings and schedules in Revit, I could equate component fields to instance parameters and the type fields to type parameters. I don’t know if other software uses the same terminology, but I assume they apply the same principles. The instance is each individual existence of an asset, the type is the product information. I could have three instances of the same type of generator.
Beginning to understand
I began to understand the structure, so what was I trying to achieve? For starters, I wanted an equipment schedule: what’s in the building, what is it called, what information can be provided about it?
Understanding now that a component sheet defines the individual instances of products, I needed to be able to specify this to my team of caddies and inform engineers without being ambiguous and while remaining auditable. I like to use SMART criteria:
- Specific - so I know what to put in and others know what to expect;
- Measurable - as I need to check the COBie file is valid and can be used;
- Achievable - because I can’t provide what I don’t know;
- Realistic - as I still have to do it; and
- Time bound - we have deadlines and I don’t want to overcommit. What client will say no when you offer anything, whether they understand it or not?
Here’s what I decided to do for each field heading, and how I worked it out. I have included the Sheet and the Name, the description provided in NBIMS for each. I’d be interested to hear if people have done something similar. How have you defined what is required in each field? How have you understood this part of COBie?
Field heading: Component.Name
“The Component.Name should be what the asset is called on the drawing. It needs to be unique, which is what I would do when creating equipment layouts.”
Steven Adams
NBIMS description: “The Component.Name must match the value found on design drawing schedules at the equivalent project stage of the current deliverable. For equipment scheduled by Type (and not Component) naming requirements to ensure unique names for every component shall be specified by contract.”
This should be what the asset is called on the drawing. It needs to be unique, which is what I would do when creating equipment layouts: GEN1, GEN2, GEN3, etc. This seems to make me an outlier. I tend to see others' Component.Name as a concatenation of family names and IDs. I see no value in passing to the FM what I have called my Revit family.
The BIM Interoperability Tools in Revit default the Component.Name builder to Revit Category and Mark. I wouldn’t use that on my drawings – I don’t use Mark in Revit, but that’s another story. I went with the equipment reference on my drawings to see if it worked.
CreatedBy, TypeName and Space are all foreign keys (i.e. they look up another table) so I’ll come back to them. For DateCreatedOn, I’ll default all of these to ISO 8601 format (yyyy-mm-dd) as specified in the British Standard for Delivering COBie.
Field heading: Component.Description
NBIMS description: “A general text description of the component.”
Hmm, I need rules so this is unsatisfactory. What would I put on a drawing or in a schedule? For a generator, I’d put ‘Generator’ written in full, sometimes also the capacity. I’m thinking that applies to most equipment I give notation to on a drawing or schedule. For example, 1,500 kW Chiller or 3 l/s Pump. So, to define the rule for this, I want the “Capacity” followed by the equipment description.
Fortunately I already have a list of equipment descriptions as I’ve standardised how I reference equipment. For example, Generator is referenced as GEN, Air Cooled Chillers as CH_A.
Field heading: Component.SerialNumber
NBIMS description: “The serial number of the installed equipment. Component.SerialNumber must match the value found on installed equipment nameplates. During planning and design phase: not applicable.”
The key piece of text for me here is “during design and construction: not applicable”. Yes, everything has a serial number, but I realised that for each field I need to state at which stage I’ll deliver it. Component.Name is needed at Stage 3. Component.SerialNumber is needed after the asset has been installed, at Stage 6.
Also, is it realistic to expect me, modelling light fittings, to find the serial number of each luminaire in a building? Perhaps in an ideal world, but the effort vs reward doesn’t stack up. Does a facilities operator currently know the serial number of each fitting? I’d wager not. This one needs revisiting and a chat with facility operators.
There are two other fields in the component sheet I won’t be able to complete until handover. These are: Component.InstallationDate and Component.WarrantyStartDate.
Field heading: Component.InstallationDate
NBIMS description: “The date on which the product or equipment was placed in its final location. During planning and design phase: not applicable.”
This seems simple enough: ISO 8601 format.
Field heading: Component.WarrantyStartDate
NBIMS description: “The date on which the product or equipment was first powered. During planning and design phase: not applicable.”
My handover engineer said “the date on which the product was handed over” is when we’d normally start the warranty. They also suggested we should provide a commissioned date. Extra fields. Hold your horses on that one please.
We also have TagNumber, BarCode and AssetIdentifier. They’re all N/A in the sample file and they all look like this in handover information. I’ll get my asset list sorted first and worry about this later.
So that’s the information I’m typing into my component fields. There are not many to fill in as most of the information would be per product, so I want to look at the Type Sheet next in part two of this series.
Don’t miss out on BIM and digital construction news: sign up to receive the BIMplus newsletter.
